分布式中间件之Redis

what is Reids?

redis是一个内存式数据库，它支持五种数据类型string、hash、list、set、zset

why use the Redis?（从性能和并发两个角度出发）

性能：碰到执行时间久且sql变化不大的操作，适合放进redis中redis一秒能进行十几万的I/O大大缩短了请求时间。

并发：大并发情况下，所有请R求直接访问数据库会导致数据库压力大，可能导致系统崩溃或者宕机，redis可以减少数据库的压力。

    redis缺点

                1.缓存和数据库双写一致性问题

                2.缓存雪崩问题

                3.缓存穿透问题

                4.缓存的并发竞争问题

    为什么redis这么快

                1.纯内存操作

                2.单线程操作，避免了频繁的上下文切换

                3.采用了非阻塞I/O多路复用机制

    redis主从复制：主节点负责写操作，从节点负责读数据，定期主节点会同步数据给子节点

    主从的缺点

                1.主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主

                2.主从复制主节点的写能力单机，能力有限

                3.单机节点的存储能力也有限

       哨兵机制：解决主从的缺点

    哨兵机制的高可用：当节点出现故障时，由哨兵自动完成故障发现和转移，并通知应用方实现高可用，整个过程只需要一个哨兵完成（采用选举算法选举出来一个哨兵来完成转移和通知）

    无磁盘复制分析：将redis的数据生成一个RDB文件，服务器会将这个文件发送给slave服务器，slave服务器将读取这个RDB文件最终做到数据一致性

    Redis管道技术：一种异步接收请求方式，客户端发送多条请求不用像同步那样等待其返回结果，管道对请求进行压缩在进行处理大大提高了系统性能

    Redis缓存与数据库一致性问题解决方案

              1.采用延时双删策略：在写数据库之前先删缓存并设置合理的超时时间，具体步骤是：先删除缓存，再写数据库，休眠500毫秒、再次删除缓存

                            缺点：在超时时间内数据存在不一致，而且又增加了写请求的耗时

              2.异步更新缓存(基于订阅binlog的同步机制)：读取mysql的binlog进行分析得到写入数据，把写入数据发送给订阅消息中间件，得到最新数据进行更新redis

    redis持久化机制

            1.AOF持久化：对每条写入命令作为日志，以append-only模式写入一个日志中，在redis重启时通过AOF来构建数据

                    优点：

                            a)AOF能更好的保护数据不丢失，AOF会每隔1s执行一次fsync操作

                            b)AOF以append-only的模式，没有任何磁盘寻址的开销，写入性能能高

                            c)AOF日志文件可进行读写的(如果数据被flushall的话，没有执行rewrite可以通过修改AOF日志来恢复数据)

                    缺点：

                            a)同一份文件AOF的文件比RDB大，AOF大到一定程度会做rewrite生成一个小文件将大文件删除

                            b)AOF比RDB支持的写的QPS低

                            c)恢复数据慢，不适合冷备份

            2.RDB持久化：对redis中数据执行周期性的持久化

                    优点：

                            a)每个时候redis的数据，RDB都会生成一个数据文件存储，这种方式适合做冷备

                            b)RDB对redis对外提供读写服务影响很小，redis主进程只需要fork一个子进程出来对磁盘IO进行RDB持久化

                            c)在恢复大数据集时RDB比AOF的速度快

                    缺点：

                            a)redis故障时RDB的丢失数据量比AOF大

                            b)RDB每次fork出子进程来执行生成文件时，如果文件大可能会导致客户端暂停服务

    RDB和AOF到底改如何选择？

                1)不要只使用RDB会丢失大量文件

                2)不要只使用AOF，RDB生成的快照更加健壮，AOF做冷备没有RDB做的冷备恢复数据快

                3)结合两者的优点进行使用， 使用AOF做数据不丢失和恢复数据，使用RDB做不同程度的冷备，在AOF丢失或者损坏不可用时使用RDB进行快速的数据恢复

    Redis使用常见问题及性能优化思路

                1)fork耗时导致高并发请求延时：RDB和AOF时会生成RDB快照，AOF rewrite消耗磁盘IO的过程，fork在拷贝父进程的空间内存页表会消耗一定的时间

                        优化思路：fork耗时跟redis主进程的内存有关，redis尽量控制在10GB以内

                2)AOF的阻塞问题：redis将数据写入AOF缓存每秒开一个fsync操作，主线程会检查两次fsync如果两者时间相差超过两秒，整个redis将被拖慢

                        优化思路：采用SSD提高硬盘写入速度

                3)主从复制延迟问题

                        优化思路：主从复制会导致超时严重，需要做好良好的监控和报警机制

                4)主从复制风暴问题：让多个slave从master去执行全量复制，一份大的RDB同时发送到多个slave会导致网络带宽被严重占用

                        优化思路：master挂载多个slave尽量使用树状结构，不使用星型结构

    缓存击穿，缓存雪崩，缓存穿透的概念及其预防措施

        缓存击穿：数据库和缓存没有数据，用户还不断发起请求。(ex:发送id特别大但不存在数据或者id为-1的数据，这样会导致数据库压力过大)

                解决方案:

                        1.接口校验请求的参数是否合法

                        2.缓存取不到数据，数据库也没有取到，将key-value改为key-null，缓存设置较短的超时时间

        缓存雪崩：缓存中数据大批量到过期时间，请求的查询数据量巨大，引起数据库压力过大甚至down机

                解决方案：

                        1.针对数据的需求设置不同的到期时间

                        2.对于长期使用且数据基本不变的进行永久性保存

                        3.缓存服务集群部署

        缓存击穿：大并发对一个key持续访问，当这个key失效的瞬间，大并发将击穿缓存直接访问数据库

                解决方案：

                        1.热点数据实现缓存永远有效

                        2.采用互斥锁来缓存数据