Redis相关-高性能-非关系型数据库-数据存储于内存中
- Redis哈希槽:16384个、通过CRC16检验来对16384进行取模从而决定来放在哪一个哈希槽
- 数据存储于内存中,读取写入速度快
- 支持多种数据类型,比如String、Hash、list、set、zset
- 支持事务,所有的操作都是原子性的,要么都成功,要么都失败
- 支持数据的持久化操作
- Memcahed:只支持String类型、不支持持久化操作、速度相比Redis较慢
-
Redis持久化机制(AOF追加模式、RDB全量复制)
-
RDB全量复制:
- 将数据以二进制的形式存储为一个RDB文件,容灾性好、可以将数据保存到磁盘
- RDB间隔一段时间就需要进行持久化操作,如果在这个期间发生故障,会造成数据丢失
- AOF追加模式
- 是将每一行执行的命令记录下来,在恢复数据的时候相当于把每一行命令重新执行一次
- 恢复速度慢,效率相对比较低、但是数据比较安全
- Redis异步队列
- 使用list结构作为队列、rpush生产消息,lpop消费消息,当lpop没有消息的时候,可以sleep一会进行消息重试
- 如果不使用sleep,可以使用list的blpop,在没有消息的时候会进行消息阻塞,直至消息的到来
- 如果想要实现一次生产多次消费,可以使用pub/sub 进行主题订阅模式来实现
- 当消费者下线的时候会存在消息丢失,可以使用消息队列RockerMQ
- Redis实现延时队列
- 使用sorted,以时间戳作为score、消息类容作为key
- 调用zadd来生产消息,消费用zrangeByScore指令获取N秒之前的数据进行轮询处理;
- Redis分布式锁-执行Reddssion
- 在高并发的情况下、可以生产唯一ID作为值,用key和value来判断,从而释放锁
- 先用setnx来争抢锁,抢到之后,用expire给锁加过期时间,防止锁忘记释放
- 如在setnx之后执行erpire之前进程意外终止的,锁得不到释放的话,可以将setnx和expire合成一条命令执行;
Redis-缓存雪崩-缓存穿透-缓存击穿
- 缓存雪崩
- 由于原有缓存失效,新的缓存还没到来,所有原本应该访问缓存的请求都去数据库进行查询了,给数据库的内存和CPU造成巨大的压力,导致数据库的宕机,从而形成的连锁反应导致系统崩溃。
- 解决: 用加锁或者队列的方法来保证不会有大量的线程一次性对数据库进行读写,从而避免失效时大量的并发请求落到底层存储系统上。
- 缓存穿透
- 缓存穿透是指用户在查询数据时,缓存中没有,并且数据库中也没有,这样就导致用户在查询的时候,返回的值是空,相当于进行了2次无用查询。
- 解决: 将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。(布隆过滤器)
- 布隆过滤器
- Bloom-Filter算法的核心思想就是利用多个不同的Hash函数来解决“冲突”。
- 缓存击穿
- 指一个key非常热点,大并发集中对这个key进行访问,当这个key在失效的瞬间,仍然持续的大并发访问就穿破缓存,转而直接请求数据库。
- 解决:分级缓存
- 采用分级缓存方式,第一级缓存失效时间短、第二级缓存失效时间长、请求优先从一级缓存中获取数据,
- 如果 一级缓存未命中则加锁,只有 1 个线程获取到锁,这个线程再从数据库中读取数据并将数据再更新到到 一级缓存缓存和 二级缓存中,
- 其他线程依旧从 二级缓存获取数据并返回。
Redis集群部署
- 主从复制
- 新增一台从服务器的时候,从服务器slave会向主服务器(master)发送一条sync请求命令,master接收到命令后通过bgsave保存数据(格式为rdb的二进制数据),
- 并使用缓冲区保存当前时间段内执行的写命令。
- master将保存的rdb文件发送给slave从服务器,并继续记录执行的写命令。
- slave接收到文件后,加载rdb数据,载入数据到从服务器中。
- 主服务器master发送完rdb数据后,开始发送缓冲区的写命令,slave从服务器接收到命令后并执行,完成初始化操作。
- 此后masert主服务器每执行一次新的命令都会同步给从服务器slave,保持主从服务器的数据一致性。
优点 - master主服务器可以将数据自动同步到从服务器上,可以进行读写分离,分担主服务器的读压力。
- master主服务器和slave从服务的同步是以非阻塞方式进行的,同步期间,客户端仍可以提交查询或更新请求。
缺点 - 不具备自动容错和恢复功能、主服务器或从服务器的故障都可能导致客户端请求处理失败。需要等待服务器重启或者客户端重新修改ip才可使用。
- 当master主服务器出现异常,如果数据没有同步完,会出现主从服务器的数据不一致。
- 难以扩容
- 哨兵模式
- 哨兵模式基于主从复制模式,引入了哨兵来监控 、自动处理故障,一旦出现问题可以作出相应的应对处理。
- 定期给master和salver发送info命令
- 定期向master、slave和其他哨兵发送PING命令。
- 如果被Ping的数据库或节点超时未回复,哨兵会认为其主观下线,如果下线的是master,哨兵会向其他的哨兵发送命令,询问其它哨兵该master是否异常,如果达到一定数目的投票,确认该master异常了,会选举其他的从服务器来作为主服务器,哨兵会将出现异常的主服务器故障恢复,恢复之后将其作为从服务器继续运行。
优点 - 哨兵模式下,master挂掉可以自动进行切换,系统可用性更高。
缺点 - 难以扩容,同样继承了主从复制的优点
- cluster集群
- Cluster模式实现了Redis的分布式存储,即每台节点存储不同的内容,来解决在线扩容的问题。
- 整个集群的部分节点失败或者不可达的情况下能够继续处理命令。
- Redis哈希槽:16384个、通过CRC16检验来对16384进行取模从而决定来放在哪一个哈希槽