list set zset hash
set 命令 edis/src/t_string.c
list lpush lpop / 有ziplist 和双向链表组成
hash 有两个hashtable ， 一个是内容一个谁拿来扩容
set 谁由intset 和 hashtable组成
zset ziplist+ skiplist
aof 谁append only file 都是可读的文本 rdb谁整个盘快照
4 redis 淘汰
noeviction:如果缓存数据超过了maxmemory限定值，并且客户端正在执行的命令(大部分的写入指令，但DEL和几个指令例外)会导致内存分配，则向客户端返回错误响应 allkeys-lru: 对所有的键都采取LRU淘汰 volatile-lru: 仅对设置了过期时间的键采取LRU淘汰 allkeys-random: 随机回收所有的键 volatile-random: 随机回收设置过期时间的键 volatile-ttl: 仅淘汰设置了过期时间的键---淘汰生存时间TTL(Time To Live)更小的键
Redis Cluster master-replica model
In order to remain available when a subset of master nodes are failing or are not able to communicate with the majority of nodes, Redis Cluster uses a master-replica model where every hash slot has from 1 (the master itself) to N replicas (N-1 additional replica nodes).
In our example cluster with nodes A, B, C, if node B fails the cluster is not able to continue, since we no longer have a way to serve hash slots in the range 5501-11000.
However when the cluster is created (or at a later time) we add a replica node to every master, so that the final cluster is composed of A, B, C that are master nodes, and A1, B1, C1 that are replica nodes. This way, the system is able to continue if node B fails.
Node B1 replicates B, and B fails, the cluster will promote node B1 as the new master and will continue to operate correctly.
However, note that if nodes B and B1 fail at the same time, Redis Cluster is not able to continue to operate.
当master 失去连接后，slave会向master 发起一个paxos 选票
Redis Cluster is not able to guarantee strong consistency. In practical terms this means that under certain conditions it is possible that Redis Cluster will lose writes that were acknowledged by the system to the client.
The first reason why Redis Cluster can lose writes is because it uses asynchronous replication. This means that during writes the following happens:
Your client writes to the master B. The master B replies OK to your client. The master B propagates the write to its replicas B1, B2 and B3.