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()提前生成一些连接。