Redis is an open source (BSD licensed), in-memory data structure store！
欢迎转载，转载请注明出处
刚刚结束一个游戏类的活动项目，由于预估的参与人数较多，产生的数据量会很大，为了达到更好的游戏效果，所以决定抛弃之前Mysql为主Redis为辅的存储方式，而是Redis为主，Mysql为辅（负责落地一些重要的用户数据），期间收货了很多。
一、Redis中的数据结构以及常见的使用场景
常用的Redis数据结构：
- String # 键值对
- List # 列表
- Hash # 哈希
- Set # 集合
- Sorted Set # 有序集合
每种数据结构都有其合适的使用场景，但是谨记 不要手里握着锤子，看什么都是钉子 。另外当存储的数据量较大时，要注意每个操作命令的时间复杂度
1、String
常用命令: set,get,decr,incr,mget 等。应用场景：String类型是最简单也是最常用的redis数据结构，key/value格式完全可以取代Memcached作为缓存服务器，单机的测试效果显示redis的效果更好。
set、get：最简单的数据缓存
mset、mget： 批量操作，把数据统一传回客户端，节省网络io时间
decr、incr：计数器
append命令：可以作为时间序列，配合getrange、setrange，对字符串进行操作，目前redis还木有修剪操作
setbit、getbit： 省内存的好命令，可以作为简单的布尔过滤器来判断用户是否执行过某些操作
2、List
常用命令：lpush,rpush,lpop,rpop,lrange等。
应用场景：List的应用场景很多，应用也相当广泛
lpush、lpop：天然的队列操作，轻松实现队列任务，Celery的存储容器我们选的就是redis
lpush、ltrim： 显示最新的数据，很好用的！比如：游戏上方的跑马灯，就可以用这两个命令来存储最新的50条记录
还有一些其他操作：堵塞式的blpop， lrange（O(n)）， lindex（O(n)），linsert（O(n)）， llen（O(1)），lrem(O(n))，lset(O(n))
3、Hash
常用命令：hget,hset,hgetall 等。
应用场景：以前在memcached中如果保存一个大的数据，经常用序列化之后保存，取出来反序列化后使用，即不经济实惠，在高并发下还存在原子性问题，在redis中， 用哈希实现，so easy啦！
hget、hset： 实现一个key对应一个数据集集合，数据集集合里包含多个单独的key/value键值对，操作依然是原子性的
hmget、hmset、hgetall： 批量操作，节省网络io时间哦
hincrby: 对哈希里域值，进行原子性的加1
其他操作： hdel（O(n)）、 hkeys（O(n)）、hexits（O(1)）、hvals（O(n)）、hscan（O(n)）
4、Set
常用命令：
sadd,spop,smembers,sunion 等。应用场景：set与list类似，只是set是经过去重的集合，需要一个不重复的数据结构，就要考虑考虑set
sadd： 存储一个不重复数据的数据集合
sunion、sdiff、sinter： 进行集合处理，例如微博中，将一个用户关注的所有人放入set集合中，通过并集、交集、差集操作，实现`共同关注`、`共同喜好`、`二度好友`等功能
其他操作：srem、spop、scard、sismember、smove、srandmember
5、Sorted Set
常用命令：
zadd,zrange,zrem,zcard等应用场景：set是无序的，而Sorted set 顾名思义，它是有序的，由key、member和score组成，需要一个有序而且不重复的数据结构，就要考虑考虑sorted set
zadd：存储一个按照score排序的数据集合，添加时自动排序，例如：优先队列，普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。
zrange、zrangebyscore等等：按照score顺序获取数据集，例如：微博的时间流信息，把发布时间作为score。还可以用来处理过期数据。后台任务使用ZRANGE…SCORES查询排序集合，取出最新的10个项目。如果发现unix时间已经过期，则在数据库中删除条目。
zrank： 排行榜功能，score作为投票结果
其他操作：zcard、zcount、zincrby、zrem、zscore，以及set的集合操作
二、Redis使用经验
先贴出来国内外三家重度使用redis的公司的使用经验，猛戳这里
一、Redis部署
本司由于平时的数据量不大，一直使用的三台redis实例，一主两从，三个哨兵sentinel分别监视三个redis实例作为高可用性的保障，这次活动的预估参与人数以及请求并发量很大，所以为了保证高可用性，在部署时做了一下变更方案：
- 更换SSD硬盘，并增加内存至128G （简单粗暴，效果显著）
- 双机房两组Redis实例，一组对外服务，另一组作为热备份，不提供服务并定时备份，服务中的实例出现故障，立即切换备份实例为服务实例
- OS参数：vm.over_commit_memory配置 默认为0，改为1
Redis的快照、AOF文件重写、主备同步等功 能都依赖于fork系统调用，以快照（bgsave/save）为例，Redis会fork一个子进程出来，由子进程来将当前的数据存储为一个RDB文件。
vm.over_commit_memory会影响到内存分配，其值可以是：
- 0： 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。
- 1： 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。
- 2： 表示内核允许分配超过所有物理内存和交换空间总和的内存。
vm.over_commit_memory默认值为0，在该配置下，当Redis执行fork时，服务器可用内存必须大于Redis当前使用内存2倍时，fork才能成功。
而实际上Linux在fork时，使用COW(copy-on-write)技术，子进程共享父进程的地址空间，只有共享地址空间发生改变时，才需要复制改变部分的内存；大部分情况下，fork子进程并不会导致内存使用翻倍，为fork预留一倍的内存是完全没有必要的，Redis启动时也会建议使用者将vm.over_commit_memory设置为1。
- OS参数：vm.swapiness设置为0
Redis是全内存的KV数据库，当服务器内存不足时，OS的swap机制可能会把Redis的部分数据换出到磁盘，访问Redis时，如果被访问的数据刚好不在内存里，则会产生缺页中断，从磁盘读取数据，这种行为会极大的影响Redis服务的性能。
为保证Redis服务的性能，应该尽量避免发生swap，将vm.swapiness设置为0（该参数可在0-100之间取值，默认为60，越高使用swap空间的可能性越大）。
- OS参数：transparent hugepage
Linux-2.6.38内核引入透明大内存页的支持，这个参数对Redis有利有弊。
- 好处在于：大内存页意味着更小的页表，fork的开销会降低不少
- 坏处在于：大内存页，意味着页被修改的几率更大，COW时拷贝成本更高
仅供参考，目前未使用该特性。
我的Redis的配置文件， 内容如下：（配置文件详细介绍请点这里）
daemonize yes pidfile "./redis.pid" port 6379 timeout 0 tcp-keepalive 60 loglevel notice logfile "./redis.log" databases 16 save 900 1 save 300 10 save 60 10000 tcp-backlog 511 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename "redis.rdb" dir "./redis" slave-serve-stale-data yes slave-read-only yes repl-disable-tcp-nodelay no slave-priority 100 maxclients 20000 maxmemory 60gb maxmemory-policy noeviction appendonly no # 可以忍受一小段时间内的数据丢失，所以关闭了aof持久化 appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-rewrite yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb lua-time-limit 5000 slowlog-log-slower-than 10000 slowlog-max-len 128 hash-max-ziplist-entries 512 hash-max-ziplist-value 512 list-max-ziplist-entries 512 list-max-ziplist-value 64 set-max-intset-entries 512 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 activerehashing yes client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 hz 10 aof-rewrite-incremental-fsync yes # Generated by CONFIG REWRITE # 由sentinel自动故障转移生成的 #slaveof 10.181.60.113 6382 slaveof 10.181.254.157 6379
二、压测过程中遇到的问题及解决方案
保证服务可靠性，对主要单接口压测，以及复合场景下的多接口压测，观察接口的响应时间以及服务的吞吐量，还有对突发情况下的Redis机器故障转移，如机房断电，主redis挂掉等情况。
问题：
- 业务逻辑复杂，频繁访问redis，接口响应时间有提升空间
- 线上要清空一个db的数据，执行flushdb后，数据依然存在（原因：该db内数据量大，清空操作超过3秒，sentinel发现3秒内，master无正确响应，就将slave拉起作为master，从进行同步，陷入循环。。。）
- Redis目前的主从同步机制，主从连接断开后，如果从落后的数据超过1M（可配置，越大内存开销越大），则需要重新全量同步一次，一次全量同步会产生极大的内存、磁盘、CPU及网络开销。主从全量同步过程中，如果写入比较多，主从同步缓冲区就会不断累积写入的数据，当累积的数据超出限制时，主从连接就会断开，此时从又必须重新向主请求全量同步，如此往复… 导致同步一直不能成功
- 数据量很大时，redis的bgsave操作，虽然是子进程操作，但是也会阻塞redis，导致超时
方案：
- mysql读写分离，并分库，分表
- redis数据分片，把重要、不重要的数据分开到两个redis实例分别存放
- 代码中减少redis网络IO请求，多用mget、hmget、pipeline等一次性读多条数据命令
- 代码中考虑用更合适的redis数据结构以及时间复杂度少的命令。 Instagram公司优化Redis使用内存案例
- 设计数据结构时，尽量减小单个key的value大小，如果单例redis中数据量过大，故障恢复或者同步过程会很慢。单例redis最大使用内存一定要小于机器最大内存的一半。
- 清空一个数据量很大的db前，先调大sentinel的自动故障转移时间，清空后再设置回来。
- 适当扩大client-output-buffer-limit slave 256mb 64mb 60 的配置值
- 一定要设置限流，运维层限制一道，代码层限制一道，保证整体服务器不宕机。
备选方案：
- 复杂的redis操作，可以考虑用短小的lua脚本执行，用eval和evalsha命令执行（优点：充分利用CPU，减少网络IO时间。缺点：不方便维护，要保证脚本不阻塞）
- 传统的一主多从A–B&C 当把B拉起为master时，C仍然会清空自身数据来同步B，psync的断点续传对此无作用，所以考虑改为变为A–B–C同步结构
- redis集群（时间紧，考虑但是暂时不会采用）
- 采用主不开持久化，从开持久化，不会出现数据量大，bgsave导致的连接超时情况（缺点：A–B&C模式下，A故障并自动拉起或者由sentinel把B被拉起为master，中间的心跳检测过程中，还是会有一个间隔，导致从同步主，发现A没有数据，会清空自身的数据，很危险！）
