2303_80341387的博客

在一个分布式系统中，也会涉及到多个节点访问统一公共资源的情况。此时就需要通过锁来做互斥控制，避免出现类似于“线程安全”的问题。而Java的synchronized或者C++的std::mutex，这样的锁都是只能在当前进程中生效，在分布式锁的这种多个进程多个主机之间就很难产生制约，分布式系统中多个进程之间的执行顺序也是不确定的。此时就需要分布式锁。

缓存是一个相对的概念，访问速度快的设备可以作为访问速度慢的设备的缓存。CPU寄存器 > 内存 > 硬盘 > 网络。缓存速度虽然快，但是空间小，缓存之所以有意义，是由于二八定律（20%的数据能够应对80%的请求）。

节点之间通过心跳包通信，心跳包中包含了该节点持有哪些slots.这个是使⽤位图这样的数据结构表示的. 表示 16384 (16k) 个 slots, 需要的位图大小是 2KB. 如果给定的 slots 数更多了, 比如 65536 个了, 此时就需要消耗更多的空间, 8 KB 位图表示了. 8 KB, 对于内存来说不算什么, 但是在频繁的网络心跳包中, 还是⼀个不小的开销的.

再控制其他节点，执行slave of，让这些其他节点，作为新的主节点的从节点。多个哨兵进行投票，一个哨兵节点一票，多个Redis都认为这个Redis服务节点挂了（达到了法定票数）就认为这个Redis服务节点挂了。哨兵节点通过心跳包，判断Redis服务器是否正在正常工作，如果心跳包没有如期而至，就认为该Redis节点主观下线了。哨兵节点会自动的通知客户端程序，告知新的主节点是谁，并且后续客户端再进行写操作，就会针对新的主节点来进行操作。哨兵节点不负责存储数据，只是对其他的redis服务节点起到监控的作用。

主节点将从生成RDB到接收完成期间主节点执行的写命令，写入到复制缓冲区中，等从节点保存完RDB文件之后，主节点再将缓冲区中的数据不发给从节点，不发的文件仍按以rdb的二进制格式追加写入到收到的rdb文件中，保持主从一致性。主节点可以进行读操作和写操作。本来在主节点上保存一堆数据，引入从节点之后，就是要把主节点上的数据复制到从节点上，后续如果主节点的数据有修改，也会同步到从节点上。主节点只需要同步部分从节点，剩下的节点交给从节点慢慢的去向从节点的从节点进行同步，这样主节点就不需要那么高的网络带宽了。

Redis的事务是否保证了原子性，这件事是存在争议的。原子性原本的含义：把多个操作打包在一起，要么 全部执行，要么全都不执行。Redis是做到了上述的原子性的含义的，但是Redis事务中的若干个操作，如果存在有操作失败，不会有回滚操作，错就错了。

所以子进程中的数据状态时父进程fork之间的数据状态，那fork之后父进程依旧在处理请求，这期间对内存的修改，子进程是不知道的。子进程并不需要读取 硬盘上哪个庞大的旧的AOF文件，而是遍历当前内存数据库中的所有数据，为每个键值对生成一条最精简的命令，并将其写入一个新的临时的AOF文件。在两次生成快照的中间，redis接收接收到了大量的key变化的请求，生成下一次快照之前，redis服务器挂了，那么中间这些key的变化就全丢了。写硬盘的时候，写入硬盘的数据的多少，对性能没有很大的影响。

如果在分布式系统中采用定义变量来存储数据的话是不能满足我们的需求的，定义的变量是只能在当前的服务器的进程的内部可以进行通信的。硬盘相当于对内存的数据备份了一下，如果redis重启了，就会在重启时加载硬盘中的备份数据，使Redis的内存恢复到重启前的状态。一个Redis能存储的数据是有限的，如果想存储更多的数据，就可以引入多个主机，部署多个Redis节点，每个Redis存储数据的一部分。Redis是在分布式系统中，才能发挥威力的，如果只是单机程序，直接通过变量存储数据的方式是比使用Redis更优的选择。

此时就可能会导致某个硬件资源不够用，无论是哪方面的资源不够用了，都可能会导致服务器处理请求的时间变长，甚至会处理出错，这极大的降低了用户的体验感。数据库服务器，就需要更大的硬盘空间，更快的数据访问速度，，就可以配置更大硬盘的服务器，甚至可以使用SSD硬盘。为了更方便代码的维护，就可以把一个复杂的服务器拆分成多个的，功能更单一，但是更小的服务器。通过增加应用服务器的方式，解决了处理更高请求量的问题，但是随着请求量的增加，对应的存储服务器要承担的请求量也会更多，此时就引入了读写分离，这种方式会比较麻烦。