redis持久化

                                                      

redis  的持久化，单机？ 多机？有哪些问题？   分布式？

   （cap、paxos、raft、akf）redis 本身是单机小程序

     mysql 的持久化方案？  异地备份，容灾，日志 

     redis，namenode 这些内存级持久化方案？ 

     方案一：  redis，namenode，mysql 都可以拍快照， bak压缩文件，RDB，image。 但每次都是全量的，假如每小时一次，丢失量比较大，出来的文件类似java序列化，体积和库相近，回复速度 快 就是io  read 。

     方案二：日志  AOF  趋向于实时，记录的是操作，但也会丢失 由于redis 的worker 是单线程，redis是内存级，一个worker 在写到磁盘上同步，就会慢很多。os ：pagecache 页缓存  每次丢的量  5s/10%  内存  批量写，可能丢很多。可以设置每秒批量写

                                                                     

      redis 默认使用RDB（快照），手动开区AOF（重启只会读aof，就不用快照了）。如果AOF太大就不好了，4.x 以上的redis ，失效，重复，无用的操作，会重写AOF ，就是快照+AOF，就是混合持久化

                                                                                  

     持久化使用场景：redis 就是快，内存，AOF就慢，如果是做缓存就可能不需要持久化，redis服务重启，都去查库，量大可能击穿库，再就是缓存是不是考虑丢失？如不考虑可以使用最快方法。可以通过网络主从复制缓存。

     

单机的技术，存在两类问题，1.单点故障不可用   2.压力/性能

     问题一的方案：全量集群，主从复制（主备高可用），一个坏了，另一个接上对外服务。

     问题二的方法：扩容？分片，多个机器存一部分数据，加上方案一统称为集群，可用性，和可扩展性

    集群就考虑cap问题。cap理论   分布式系统中的CAP理论，面试必问，你理解了嘛？

      强一致性，后续同步失败会导致，不返回成功，GG。弱一致性可能同步失败

  从的redis 挂了，回去黑盒子里同步数据，黑盒技术paxos论文，zk有实现，就投票和主从机

 

     客户端都找到一个redis分配算法（可以类似hash），对数据分片，两个redis互相通信，每个redis自带一个mapping，也知道其他的mapping，数据来了随便找到一个redis，算法告诉如果不在此节点，也会指定在哪个节点存在不同的redis。如果想增加新的redis节点，只要迁出去几个slot，不用全部rehash

一致性哈希环，和固定slot 

一致性哈希和哈希槽对比 - 简书