Tips for better reading experience: [battle] Xi'erqi | Redis interview hotspot of engineering architecture articles [2]
Foreword
Front with three articles describes some of the underlying implementation issues related to architecture and engineering, in view of the hot issues Redis or more, so today continue to look at issues related to infrastructure projects, interested can first review the previous three article, as follows:
[battle] Xi'erqi | Redis interview hotspots of the underlying implementation of article
[battle] Xi'erqi | Redis interview underlying hot spot implement articles (cont.)
[battle] Xi'erqi | Redis interview hotspot of engineering architecture articles
In this article you will learn the following:
- Redis data synchronization
persistence and synchronization of data relationships, CAP choice Redis distributed storage, Redis data synchronous and asynchronous replication, replication and incremental copying the full amount of principle, diskless replication.
Q: Talk about your understanding synchronize (copy) the data Redis it!
Persistence and data synchronization relationship
Appreciated relational persistence and synchronized data, from a single point of failure and the need for high availability two angles Analysis:
Single point of failure downtime
If we now only as a cache Redis machine, hot by the persistent data is written to disk, a single point in time the machine fails Redis downtime, during a cache miss, the main memory to service all requests withstand pressure multiplier, Redis machine downtime monitoring program will pull up.
After the restart, the machine can Load RDB data disk for fast recovery, recovery time depends on how much data amount, generally ranging from seconds to minutes, grade level, before the recovery is complete guarantee is still hot data, CacheMiss such storage systems will reduced, effectively reducing the impact of the breakdown of the cache.
Persistence mechanism is very useful for a single point in Redis, just write the text easier to let everyone fall asleep, I drew a diagram :
Redis highly available system
As a single point down a cache system availability is not allowed, so there have one master node to a plurality of data backup master, the master node if the mount point, the state can immediately switch from the best node the master node, provide external writing services, and other nodes to synchronize data from the new primary node, ensure high availability throughout the Redis caching system.
FIG showing a main process of a failover from two separate read and write system Redis master node, and the process does not stop working, greatly improving the availability of the system:
From the above analysis, two conclusions can be drawn a little planning [emphasis]:
persistence to make single points of failure no longer terrible, data synchronization for high availability wings.
We understand the important role of synchronization data Redis, and then continue to look at the data synchronization process and the principle of the details, such as heavy and difficult it!
CAP theory Redis system
Have knowledge of the distributed storage readers will know that CAP theory, I am ashamed to say, when in March 2018 to change jobs, when to Face ++ Kuang surface of the rear, as the technology development positions encountered CAP theory, in addition to theoretical issues outside the CAP other issues are within range, so eventually took the Offer.
But he impressed the interviewer said T graduating previous question answer was good, why did they have to answer questions CAP dish so ... In fact, I only know the CAP theory as rich handsome, like, not so easy to achieve ... no details clear ... you eat melon readers, the author said earlier the purpose of this little thing is to express: CAP theory is very important for understanding distributed storage, next time you interview asked about blame I did not warn CAP.
In theoretical computer science, CAP Theorem is also known as Brewer's theorem Theorem Brewer , the theorem originated in the University of California, Berkeley computer scientist Eric Brewer in 2000 on the principle of distributed computing seminar PODC proposed one guess .
In 2002, MIT Seth Gilbert and Nancy Lynch published Brewer prove conjecture , making it a Theorem . It pointed to a distributed computing system, can not simultaneously meet the following three points:
- C Consistent consistency consistency
- A Availability Availability
- P Partition Tolerance partition tolerance
Ruan Yifeng Gangster look at a picture of the chart:
For a simple example, explain the compatibility of CP and AP:
CP and AP issues
key to understanding the AP and CP that partition tolerance P, in the distributed storage network partition commonplace, even in a machine room, but also can not all in a rack or a switch.
This will appear in the LAN network jitter, the author has done for more than a year DPI transmission network in the most profound of three terms: packet loss, out of order, retransmission . So our view is calm network, it may be stormy in servers , accidentally stuffed up, so when the network is disconnected, then appeared the network partition problem.
For Redis data synchronization, it is assumed that the master node and the node on the two racks, a network disconnection time of occurrence, at this time Redis if separate read and write, then the data from the node can no longer necessarily synchronized with the main data . In this case, if it continues to cause data inconsistencies in reading data from the node, if the force to ensure consistency of data from the node can not provide the service is unavailable cause problems, so be seen that under the influence of the P and A can not be C into account.
Several other cases will not go up, we can conclude from the above: When Redis multiple machines distributed in different network, if a network failure occurs, the data consistency and service availability can not be both, Redis system which must do the selection, in fact Redis chose to availability, or Redis chose another eventual consistency.
Eventual consistency
Redis chose the eventual consistency, that is no guarantee that the data from the master at any time are the same, and the default Redis master-slave synchronization is asynchronous, honey pots faithful not faint! Do Monte ring!
Let me explain what synchronous and asynchronous replication (Note: consider the feelings of the readers I did not write synchronous and asynchronous synchronization sync ha ha) :
一图胜千言，看红色的数字就知道同步复制和异步复制的区别了：
- 异步复制：当客户端向主结点写了hello world，主节点写成功之后就向客户端回复OK，这样主节点和客户端的交互就完成了，之后主节点向从结点同步hello world，从结点完成之后向主节点回复OK，整个过程客户端不需要等待从结点同步完成，因此整个过程是异步实现的。
- 同步复制：当客户端向主结点写了hello world，主节点向从结点同步hello world，从结点完成之后向主节点回复OK，之后主节点向客户端回复OK，整个过程客户端需要等待从结点同步完成，因此整个过程是同步实现的。
Redis选择异步复制可以避免客户端的等待，更符合现实要求，不过这个复制方式可以修改，根据自己需求而定吧。
从从复制
假如Redis高可用系统中有一主四从，如果四个从同时向主节点进行数据同步，主节点的压力会比较大，考虑到Redis的最终一致性，因此Redis后续推出了从从复制，从而将单层复制结构演进为多层复制结构，笔者画了个图看下：
全量复制和增量复制
全量复制是从结点因为故障恢复或者新添加从结点时出现的初始化阶段的数据复制，这种复制是将主节点的数据全部同步到从结点来完成的，所以成本大但又不可避免。
增量复制是主从结点正常工作之后的每个时刻进行的数据复制方式，涓涓细流同步数据，这种同步方式又轻又快，优点确实不少，不过如果没有全量复制打下基础增量复制也没戏，所以二者不是矛盾存在而是相互依存的。
全量复制过程分析
Redis的全量复制过程主要分三个阶段：
- 快照阶段：从结点向主结点发起SYNC全量复制命令，主节点执行bgsave将内存中全部数据生成快照并发送给从结点，从结点释放旧内存载入并解析新快照，主节点同时将此阶段所产生的新的写命令存储到缓冲区。
- 缓冲阶段：主节点向从节点同步存储在缓冲区的操作命令，这部分命令主节点是bgsave之后到从结点载入快照这个时间段内的新增命令，需要记录要不然就出现数据丢失。
- 增量阶段：缓冲区同步完成之后，主节点正常向从结点同步增量操作命令，至此主从保持基本一致的步调。
借鉴参考1的一张图表，写的很好，我就不再重复画图了：
考虑一个多从并发全量复制问题：
如果此时有多个从结点同时向主结点发起全量同步请求会怎样？
Redis主结点是个聪明又诚实的家伙，比如现在有3个从结点A/B/C陆续向主节点发起SYNC全量同步请求。
- 主节点在对A进行bgsave的同时，B和C的SYNC命令到来了，那么主节点就一锅烩，把针对A的快照数据和缓冲区数据同时同步给ABC，这样提高了效率又保证了正确性。
- 主节点对A的快照已经完成并且现在正在进行缓冲区同步，那么只能等A完成之后，再对B和C进行和A一样的操作过程，来实现新节点的全量同步，所以主节点并没有偷懒而是重复了这个过程，虽然繁琐但是保证了正确性。
再考虑一个快照复制循环问题：
主节点执行bgsave是比较耗时且耗内存的操作，期间从结点也经历装载旧数据->释放内存->装载新数据的过程，内存先升后降再升的动态过程，从而知道无论主节点执行快照还是从结点装载数据都是需要时间和资源的。
抛开对性能的影响，试想如果主节点快照时间是1分钟，在期间有1w条新命令到来，这些新命令都将写到缓冲区，如果缓冲区比较小只有8k，那么在快照完成之后，主节点缓冲区也只有8k命令丢失了2k命令，那么此时从结点进行全量同步就缺失了数据，是一次错误的全量同步。
无奈之下，从结点会再次发起SYNC命令，从而陷入循环，因此缓冲区大小的设置很重要，二话不说再来一张图：
增量复制过程分析
增量复制过程稍微简单一些，但是非常有用，试想复杂的网络环境下，并不是每次断开都无法恢复，如果每次断开恢复后就要进行全量复制，那岂不是要把主节点搞死，所以增量复制算是对复杂网络环境下数据复制过程的一个优化，允许一段时间的落后，最终追上就行。
增量复制是个典型的生产者-消费者模型，使用定长环形数组(队列)来实现，如果buffer满了那么新数据将覆盖老数据，因此从结点在复制数据的同时向主节点反馈自己的偏移量，从而确保数据不缺失。
这个过程非常好理解，kakfa这种MQ也是这样的，所以在合理设置buffer大小的前提下，理论上从的消费能力是大于主的生产能力的，大部分只有在网络断开时间过长时会出现buffer被覆盖，从结点消费滞后的情况，此时只能进行全量复制了。
无盘复制
理解无盘复制之前先看下什么是有盘复制呢？
所谓盘是指磁盘，可能是机械磁盘或者SSD，但是无论哪一种相比内存都更慢，我们都知道IO操作在服务端的耗时是占大头的，因此对于全量复制这种高IO耗时的操作来说，尤其当服务并发比较大且还在进行其他操作时对Redis服务本身的影响是比较大大，之前的模式时这样的：
在Redis2.8.18版本之后，开发了无盘复制，也就是避免了生成的RDB文件落盘再加载再网络传输的过程，而是流式的遍历发送过程，主节点一边遍历内存数据，一边将数据序列化发送给从结点，从结点没有变化，仍然将数据依次存储到本地磁盘，完成传输之后进行内存加载，可见无盘复制是对IO更友好。
小结
时间原因只能写这么多了，和大家一起学习不是把桶填满而是把火点燃。
回顾一下：本文主要讲述了持久化和数据同步的关系、Redis分布式存储的CAP选择、Redis数据同步复制和异步复制、全量复制和增量复制的原理、无盘复制等，相信耐心的读者一定会有所收获的。
最后可以思考一个问题：
Redis的数据同步仍然会出现数据丢失的情况，比如主节点往缓冲区写了10k条操作命令，此时主挂掉了，从结点只消费了9k操作命令，那么切主之后从结点的数据就丢失了1k，即使旧主节点恢复也只能作为从节点向新主节点发起全量复制，那么我们该如何优化这种情况呢？
巨人的肩膀
- https://segmentfault.com/a/1190000012390817
- 钱文品-《Redis深度历险核心原理和应用实践》