redis特点:
- 单进程多线程。主线程只有一个,还有两个副线程,用于文件和 IO 处理。
- 可以集群部署,数据在各个机器上都有备份,挂了一台机器,可以从其他机器上找到数据。
- 集群带来主从节点机制,一般至少需要3个节点来选举出主节点,也可以指定主节点。
- 主从同步问题,会导致数据不一致。保证了分布式P和可用性A,牺牲了一致性C,可以保证最终一致性。比如数据恢复。
- 把数据存放到内存,从内存查找数据比较快一些。
- 有 key-string,key-list,key-zset 等存储方式,本质上就是通过 key 查找对应的数据。
- 当数据很大时,超过10KB,有性能风险。
- 当 list 长度超过5000,有性能风险。
- redis 的 setnx特性,当 key 不存在时则写入。这个特性可以用于分布式锁,能写入成功的进程获得锁,通过超时时间控制锁自动释放。
数据结构:
- string
- list:双向链表
- hash:对 key 进行 hash,找到对应的 list
- set:无序不重复集合
- zset:有序不重复集合,通过 score 控制顺序
链表和数组对比:
- 链表长度不受限制
- 链表容易插入和删除某一个节点
缓存,数据库,消息中间件:
- 主从模式:简单粗暴,master 负责写,slave 负责读,缺少控制节点。
- 哨兵模式sentinel:增加哨兵作为控制节点,当节点故障后进行剔除,并监控节点状态。
- 分片模式:一个节点的内存有限,将多个节点的内存作为一个整体内存使用。容易导致内存丢数据。
- 集群模式cluster:每个节点都保存了整个内存的副本,各个节点异步同步数据。master 节点通过动态选举产生。资源隔离性不好,不保证数据强一致性。
分布式锁
- 数据库悲观锁:行锁,表锁,排他锁。select for update,有死锁,慢查询风险。
- 数据库乐观锁:先查version,再带 version 进行 update,可能更新失败,高并发下失败量增多有性能风险。
- redis 锁:setnx+过期时间,各个 client 都尝试去 setnx,能设置成功的获取到锁。
- zookeeper 锁:share_lock+watcher,各个client需要锁操作时,client 去查share_lock列表里的第一个 path 节点(id 最小的),这个 path 节点对应 client 获取到锁,其他 client 继续保持 watch 监听。
参考: