Redis 高并发解决方案

针对大流量瞬间冲击，比如秒杀场景

redis前面可以加一层限流 sentinel ／ Hystrix

redis高并发（读多写少）下缓存数据库双写误差：

1. 修改操作使用分布式锁（就是修改的时候加锁，一次只能有一个线程修改，可以多线程读），对于读多的场景更有利；推荐（以较少的性能代价换取了绝对的一致）

2. 延迟删除缓存

修改一个key后，删除缓存，为了防止之前有线程读过旧数据然后再次写入，sleep 10毫秒再删除一次，但此步要后台处理，不然可能会大幅降低整体性能。

3. 写直接写入数据库，通过canal等中间件订阅binlog，然后将变化应用到缓存，缓存只提供读操作； 可能存在读延迟

多读写也多

1. 使用消息中间件，不推荐使用redis缓存

2. 直接使用数据库都比再加个缓存快，尤其那些高速写入又马上查询，甚至还会统计分析的业务。

Redis缓存的超时时间

要把这个因素的考虑，贯穿到所有场景。要根据自己的业务场景来设定超时时间

被动删除：过期的key不会立即删除，会在下次被get时删除。

主动删除：定期主动删除过期key

不推荐方案－一个大redis集群后面多个数据库

这相当于让并发集中在redis那里了，不仅没有提升性能，还降低了性能

要让redis集群与数据库集群一一对应，拆分开来

如果这样都行，那么直连数据库也没啥问题； 那问题来了，为啥还要浪费一堆资源弄个redis集群呢？

Redis连接池配置

对于高并发场景，配置maxTotal = maxIdle，即减少了连接创建与销毁的资源； 非高并发的场景不要这么配，因为连接的存在也是耗费资源的。

连接池预热。Redis的连接是用时才生成，如果你知道某个时间点（定点秒杀，一天都没有啥请求，就等那个时间点）会瞬间生成大量连接，可以使用使用jedis.ping()提前生成一些连接。