redis总结

1、redis是目前公认的速度最快的基于内存的键值对数据库，但redis的缺点也非常明显，仅提供最基本的hash set, list, sorted set等基于数据类型，不分表，没有schema，没有索引，没有外键，缺少int/date等基本数据类型，多条件查询需要通过集合内联(sinter,zinterstore)和连接间接实现，操作不便，开发效率低，可维护性不佳； 因此一般不将其视为完整的数据库单独使用，很多网站将redis作为高速缓存和session状态存储层，然后再与其他数据库搭配使用。

2、核心业务建议数据还是落地到mysql，redis在异常情况下回丢数据。

非核心业务，比如运营推广，数据聚合统计这种允许数据少量丢失的业务可以全用mysql，扩展方便，效率高，业务量也不大。特别是运营推广这种时效性很强的业务，在推广结束后数据接没用了，Redis内存压力也不会很大。
mysql能支持对各个字段的查询，Redis的查询仅限于对key的简单匹配，如果要对value进行复杂查询，不适合用Redis

3、

Redis是一种内存数据库，这使其在数据存取效率方面表现突出。由于内存中的数据时刻面临丢失的危险，Redis提供了两种持久化机制，及时将内存中的数据写入硬盘。第一种机制为RDB，利用存储快照的方式把内存数据定期写入硬盘；第二种机制为AOF，利用写日志的方式，每执行一条更改Redis数据的命令，就在日志里附加上该命令并保存在硬盘上。Redis默认开启RDB模式，关闭AOF模式，这是因为AOF更加耗时。但是，如果对数据安全要求极高，无法承担任何数据丢失的后果，AOF模式就变成了持久化的首选。
当然，即使Redis具备持久化机制，但是一旦本地硬盘损坏，数据丢失依然在所难免。所以，Redis又提供了复制功能，作用是将一个主数据库（master）的数据自动同步到多个从数据库（slave），从而尽可能防止数据丢失。Redis主从机制可以简单描述为：从数据库启动后，先向主数据库发送SYNC命令；主数据库接到SYNC命令后就开始保存快照，在此期间，所有发给主数据库的命令都被缓存起来；快照保存完成后，主数据库把快照和缓存的命令一起发给从数据库；从数据库保存主数据库发来的快照文件，并依次执行主数据库发来的缓存命令。在同步过程中，从数据库不会阻塞，它默认使用同步之前的数据继续响应客户端发来的命令。

一：缓存——热数据

热点数据（经常会被查询，但是不经常被修改或者删除的数据），首选是使用redis缓存，毕竟强大到冒泡的QPS和极强的稳定性不是所有类似工具都有的，而且相比于memcached还提供了丰富的数据类型可以使用，另外，内存中的数据也提供了AOF和RDB等持久化机制可以选择，要冷、热的还是忽冷忽热的都可选。

结合具体应用需要注意一下：很多人用spring的AOP来构建redis缓存的自动生产和清除，过程可能如下：

• Select 数据库前查询redis，有的话使用redis数据，放弃select 数据库，没有的话，select 数据库，然后将数据插入redis

• update或者delete数据库钱，查询redis是否存在该数据，存在的话先删除redis中数据，然后再update或者delete数据库中的数据

上面这种操作，如果并发量很小的情况下基本没问题，但是高并发的情况请注意下面场景：

为了update先删掉了redis中的该数据，这时候另一个线程执行查询，发现redis中没有，瞬间执行了查询SQL，并且插入到redis中一条数据，回到刚才那个update语句，这个悲催的线程压根不知道刚才那个该死的select线程犯了一个弥天大错！于是这个redis中的错误数据就永远的存在了下去，直到下一个update或者delete。

二：计数器

诸如统计点击数等应用。由于单线程，可以避免并发问题，保证不会出错，而且100%毫秒级性能！爽。

命令：INCRBY

当然爽完了，别忘记持久化，毕竟是redis只是存了内存！

---

三：队列

• 相当于消息系统，ActiveMQ，RocketMQ等工具类似，但是个人觉得简单用一下还行，如果对于数据一致性要求高的话还是用RocketMQ等专业系统。

• 由于redis把数据添加到队列是返回添加元素在队列的第几位，所以可以做判断用户是第几个访问这种业务

• 队列不仅可以把并发请求变成串行，并且还可以做队列或者栈使用

---

四：位操作（大数据处理）

用于数据量上亿的场景下，例如几亿用户系统的签到，去重登录次数统计，某用户是否在线状态等等。

想想一下腾讯10亿用户，要几个毫秒内查询到某个用户是否在线，你能怎么做？千万别说给每个用户建立一个key，然后挨个记（你可以算一下需要的内存会很恐怖，而且这种类似的需求很多，腾讯光这个得多花多少钱。。）好吧。这里要用到位操作——使用setbit、getbit、bitcount命令。

原理是：

redis内构建一个足够长的数组，每个数组元素只能是0和1两个值，然后这个数组的下标index用来表示我们上面例子里面的用户id（必须是数字哈），那么很显然，这个几亿长的大数组就能通过下标和元素值（0和1）来构建一个记忆系统，上面我说的几个场景也就能够实现。用到的命令是：setbit、getbit、bitcount

---

五：分布式锁与单线程机制

• 验证前端的重复请求（可以自由扩展类似情况），可以通过redis进行过滤：每次请求将request Ip、参数、接口等hash作为key存储redis（幂等性请求），设置多长时间有效期，然后下次请求过来的时候先在redis中检索有没有这个key，进而验证是不是一定时间内过来的重复提交

• 秒杀系统，基于redis是单线程特征，防止出现数据库“爆破”

• 全局增量ID生成，类似“秒杀”

---

六：最新列表

例如新闻列表页面最新的新闻列表，如果总数量很大的情况下，尽量不要使用select a from A limit 10这种low货，尝试redis的 LPUSH命令构建List，一个个顺序都塞进去就可以啦。不过万一内存清掉了咋办？也简单，查询不到存储key的话，用mysql查询并且初始化一个List到redis中就好了。

---

七：排行榜

谁得分高谁排名往上。命令：ZADD（有续集，sorted set）