Redis系列之 ——闲侃Redis

Tip：生活不易，码农辛苦
         我是小刀，在互联网中夹缝求生 我希望你开心…

序文

                本博主作为一个帅气又体贴的正经程序员（Ps：一表人才、风度翩翩，相貌堂堂，衣冠楚… 额 扯多了 差点扯到蛋），人送外号海淀陈冠希，作为一个"正经人"从来只看带图的。就看不得网上那些千篇一律的原理解释，一套下来整个人都不好了。本篇文章就想聊聊 redis ，作为一个受众最深的中间件小伙伴们肯定又爱又恨（Redis: 呸 你个渣男😭），希望能帮助各位瞌睡的小伙伴深入的理解，记的得深入…

如果有一天我变成流氓，请告诉别人，我纯真过……
                                                 

正文

    首先redis是什么？，为什么用它
    作者说是一个数据结构服务器，我们可以理解为nosql数据库。为什么要用Redis的，原因很简单，快呀。

    天空飘来三个字 为啥快？(Ps：这个问题问的好 鼓掌👏)。
    人家redis是以内存作为数据存储介质的，绝大部分请求是纯粹的内存操作所以读写数据的效率极高，远远超过老大哥mysql。可是为啥不用memcache作为中间件？（老弟来，找个没人的角落我给你解释）。首先memcache的存储数据类型没有redis丰富，最大的区别是redis有持久化特性。（Redis：老弟这个杀伤力大吧！）Redis 使用多路I/O复用，这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求，尽量减少网络 IO 的时间消耗，加上官方给出的数据是可以达到100000+的QPS（每秒内查询次数），所以造就了 Redis 具有很高的吞吐量。
                                                      

   那么问题来了为什么Redis是单线程的？
   官方说了：CPU不会成为瓶颈，瓶颈最有可能是机器内存的大小或者网络带宽，既然单线程模式的情况下已经很快了，就没有必要在使用多线程了！（Ps：打我可以别打帅脸！）

   那redis和memcache改如何选择? （Ps：拍死你咋这么多问题）
    Redis更多场景是作为Memcached的替代者来使用，当需要更多数据类型支持或存储的数据不能被剔除时，使用Redis更合适（Ps：没办法谁让人活好不黏人）。如果只做缓存的话，Memcached已经足够应付绝大部分的需求，Redis 的出现只是提供了一个更加好的选择。总的来说，根据使用者自身的需求去选择才是最合适的。

                                                         

    可否说下Redis持久化？（Ps：这个好 面试常问，工作常用）

    两种策略机制，也就是RDB和AOF。持久化功能有效地避免服务挂掉造成的缓存数据丢失问题，如果因为这个问题造成整个系统挂掉，那不得杀个程序员祭天哇（程序员：我太TMD难了）。

    先介绍RDB，其实就是把数据以快照的形式保存在磁盘上。何为快照，你可以理解成把当前时刻的数据拍成一张照片保存下来，RDB持久化是在指定的时间间隔内将内存中的数据集快照写入磁盘。也是Redis默认的持久化方式，实际操作过程是fork一个子进程，将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。但是一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。而且数据不能做到实时持久化。
    何为AOF，每一个收到的写命令都追加到文件中，以独立日志的方式记录每次写命令， 以文本的方式记录，可以打开文件看到详细的操作记录，随着AOF文件越来越大，会定期对AOF文件进行重写，达到压缩的目的，降低了文件占用空间，更小的 文件可以更快地被Redis加载。缺点是因为AOF一般会配置成每秒fsync一次日志文件，对性能也是有影响的。

    两种策略机制你明白了，剩下的就是看自己的需求了，需求不同选择的也不同，最好是选择两者加一起才更好（男女搭配干活不…）。想配置的小伙伴可以在网上查下配置参数。
                                                         

    一般来说在项目中会启用多台 Redis 服务，单个 Redis 服务器会发生单点故障，并且一台服务器要处理所有的请求，负荷太大了。这就衍生出 Redis 的主从复制（Redis：我也有小弟了 嘎嘎！），可以在配置参数中配置或者使用命令执行。不仅可以提高系统的可伸缩性还可以让读和写分离开来，小弟们专门处理读操作，老大专门处理写操作。有效提高服务器的负载能力，并且数据还被复制成了好几份，就算其中一台机器出现了故障，也可以使用其他机器的数据快速恢复。
                                                         
主从复制的工作原理：小弟们启动连接之后会特别主动的发送一个叫 SYNC 的命令给大哥，大哥收到命令之后执行bgsave命令生成RDB文件并使用缓冲区记录此后执行的所有写命令，并向所有小弟发送RDB文件，小弟收到之后丢弃所有旧数据，载入新收到的RDB文件。完事之后老大继续将缓冲区中的写命令发送给小弟，小弟完成RDB文件载入之后，开始接收命令请求，并执行老大缓冲区的写命令，最终达到数据的同步。

技术是把双刃剑，给我们带来很多好处的同时也有许多问题接踵而至。读写分离之后我们的主从配置不一致，就会发生很多诡异的问题，比如内存大小不一致，导致复制数据的丢失这个问题。机器越多复制开销也就越大，全量复制的开销还是很大的，比如第一次全量复制时可以选择在低峰的时间（凌晨）进行slave的挂载。还存在复制风暴问题（我们主节点重启之后，所有slave检测到RunID发生变化，导致所有从节点向主节点做全量复制）。

RunID：是每一台服务器每次运行的身份识别码,用于在服务器间进行传输,识别身份，启动时自动生成的。
想要实现高可用，当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。那估计杀一个程序员都不好使，不得杀一片哇！（程序员：又TM是我哇？）这时候可以用 Redis 哨兵模式来实现故障自动转移。（程序员表示‘撒浪嘿呦’！）
                                                
哨兵模式是一种特殊的模式，Redis 提供了哨兵的命令，它是一个独立的进程，作为进程，它会独立运行。原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。（Redis：你TM偷窥我😂）
每个哨兵 会向其它哨兵、master、slave定时发送消息，以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂（主观死亡），多数哨兵,都报告某一master没响应,系统才认为该master"彻底死亡"（客观死亡），在通过一定的vote算法,从剩下的slave节点中,通过投票选举出一台提升为master,然后自动修改相关配置，实现故障自动转移。（程序员：又能看到明天的太阳了！）就算有了这些还有新的问题出现，哨兵选举期间，还是不能对外提供服务。网络问题产生的机器假死（脑裂问题），这些可以自己网上查查。
以上的这些其实就满足大部分公司的面试问题（Ps：还有应用场景我就不一一介绍了）。

Redis 还提供集群模式来实现更好的可扩展性，高可用性。还能降低运维成本。相对来说技术方面也更加复杂。如果你在面试中面试官问到你这块的时候，不到万不得已的情况下千万不要说用过集群模式（Ps：除了真正用过的）。因为这个杀伤力太大，太香了。
（如果能对答如流的说明白 Redis 可能得恭喜你“不用理直气壮的啃老和天天在村口逗狗玩了”）。