linux学习进展 Redis发布订阅 主从复制 缓存 雪崩

redis发布订阅Redis发布订阅pub/sub是一种消息通信模式 发布者pub发送消息订阅者(sub)接受消息。模型redis主从复制概念主从复制指的是将一个Redis服务器的数据复制到其他的Redis服务器。前者称为主节点master/leader),后者称为从节点slave/follower。数据的复制是单向的只能从主节点到从节点。Master以写为主Slave以读为主。默认情况下每台Redis服务器都是主节点且一个主节点可以有多个从节点或者没有从节点但一个从节点只能有一个主节点主从复制的作用主要包括数据冗余主从复制实现了数据的热备份是持久化之外的一种数据冗余方式故障恢复当主节点出现问题时可以由从节点提供服务实现快速的故障恢复实际上是一种服务冗余负载均衡在主从复制的基础上配合读写分离可以由主节点提供写服务由从节点提供读服务即写 Redis 数据时应用连接主节点读 Redis 数据时应用连接从节点分担服务器负载。尤其是在写少读多的场景下通过从节点分担读负载可以大大提供 Redis 服务器的并发量。高可用 (集群) 基石除了上述作用以外主从复制还是哨兵和集群能够实现的基础因此说主从复制是 Redis 高可用的基础。一般来说用将 Redis 运用于工程项目中只使用一台 Redis 是万万不可能的原因如下从结构上单个 Redis 服务器会发生单点故障并且一台服务器需要处理所有的请求负载压力较大从容量上单个 Redis 服务器内存容量有限就算一台 Redis 服务器内存容量为 256G也不能将所有内存用作 Redis 存储内存一般来说单台 Redis 最大使用内存不应该超过 20G。环境配置一主二从默认情况下每台Redis服务器都是主节点主需要配置从机就行真实的主从配置应该在配置文件中配置这样的话是永久的我们通过命令配置的是临时的主机可以写从机不能写只能读主机中的所有信息和数据都会自动保存到从机中主机断开连接从机依旧连接到主机的但是没有写操作这个时候主机如果回来了从机依旧可以直接获取到主机写的信息。如果使用命令行配置的从机重启后就会变回主机只要在把他重新配成原来主机的从机数据依旧可以获取到。复制原理Slave启动成功连接到Master后会向Master发送一个sync同步命令Master接受到命令后启动后台的存盘进程同时收集所有接收到的用于修改数据集命令在后台进程执行完毕之后Master将传送整个数据文件(全量复制)到Slave并完成一次完全同步。全量复制 Slave服务在接受到数据库文件数据后将其存盘并加载到内存中增量复制 Master继续将新的所有收集到的修改命令一次传给Slave完成同步但是只要是重新连接Master一次完全同步全量复制将被自动执行从机恢复主机从机执行SLAVEOF no one 可以重新恢复为主机哨兵模式自动选举老大的模式主从切换技术的方法是当主服务器宕机后需要手动把一台从服务器切换为主服务器这就需要人工干预费事费力还会造成一段时间内服务不可用。这不是一种推荐的方式更多时候我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel哨兵架构来解决这个问题。某草篡位的自动版能够后台监控主机是否故障如果故障了根据投票数自动将从库转换为主库哨兵模式是一种特殊的模式首先Redis提供了哨兵的命令哨兵是一个单独的进程作为进程他会独立运行。其原理是哨兵通过发送命令等待Redis服务器响应从而监控运行的多个Redis实例。哨兵的作用通过发送命令让Redis服务器返回监控其运行状态包括主服务器和从服务器当哨兵监测到Master宕机会自动将Slave切换成Master然后通过发布/订阅模式通知其他的从服务器修改配置文件让它切换主机。多哨兵模式哨兵互相监控主管下线后投票实现客观下线 哨兵模式的优点哨兵集群基于主从复制模式所有的主从复制优点它全有主从可以切换故障可以转移系统的可用性会更好哨兵模式就是主从模式的升级手动转自动更加健壮哨兵模式的缺点Redis不好在线扩展集群容量一旦到达上限在线扩容十分麻烦实现哨兵模式的配置很麻烦里面有很多选择Redis缓存穿透和雪崩Redis缓存的使用极大的提高了应用程序的性能和效率特别是数据查询等。但同时它也带来了一些问题。其中最主要的问题就是数据一致性从严格意义上来讲这个问题是无解的。如果对数据一致性要求很高那么就不能使用缓存。1、缓存穿透 - 查不到缓存穿透的就是用户想要查询一个数据发现Redis中没有也就是缓存没有命中于是向持久层数据库发起查询发现也没有这个数据于是本次查询失败。当用户很多的情况下缓存都没有命中又都去请求持久层数据库。这会给持久层数据库造成很大的压力这时候就相当于缓存穿透。2、缓存击穿 - 量太大缓存过期这里需要注意和缓存穿透的区别缓存击穿是指一个key非常热点。在不停的扛着大量并发大并发集中对这一个点进行访问当这个key在失效的瞬间持续的大并发就穿破缓存直接请求数据库就像在也给屏蔽上凿开了一个洞。当某个key在过期的瞬间有大量的请求并发访问这类数据一般是热点数据由于缓存过期会同时访问数据库来查询最新数据并且写会缓存会导致数据库瞬间压力过大3.缓存雪崩缓存雪崩指的是在某一时间段缓存集中过期失效或者Redis宕机。比如在写文本的时候马上要到双十一零点很快就会迎来一波抢购这波商品时间比较集中的放入了缓存假设缓存一个小时。那么到了凌晨一点钟的时候这批商品的缓存就过期了。从而对这批商品的访问查询都落到了后台数据库上对于数据库而言就会产生周期性的压力波峰。于是所有的请求都会达到存储层存储层的调用量会暴增造成存储层也会宕机的情况其实集中过期倒不是非常致命比较致命的缓存雪崩是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩一定是在某个时间段集中创建缓存这个时候数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务器节点的宕机对数据服务器造成的压力是不可预估的很可能瞬间就把数据库压宕机。完整事务示例示例1用户注册事务# 用户注册检查用户名是否存在然后创建用户 127.0.0.1:6379 WATCH user:username:张三 # 监视用户名 OK 127.0.0.1:6379 MULTI OK 127.0.0.1:6379 EXISTS user:username:张三 # 检查用户名是否已存在 QUEUED 127.0.0.1:6379 INCR user:id_counter # 获取新用户ID QUEUED 127.0.0.1:6379 SET user:1001:name 张三 # 创建用户信息 QUEUED 127.0.0.1:6379 SET user:username:张三 1001 # 设置用户名索引 QUEUED 127.0.0.1:6379 EXEC # 如果在执行期间其他客户端创建了张三用户则事务失败示例2库存扣减事务127.0.0.1:6379 WATCH product:1001:stock OK 127.0.0.1:6379 MULTI OK 127.0.0.1:6379 GET product:1001:stock QUEUED 127.0.0.1:6379 DECR product:1001:stock QUEUED 127.0.0.1:6379 LPUSH orders order123,product1001 QUEUED 127.0.0.1:6379 EXEC事务的局限性不支持回滚# 如果事务中部分命令失败不会自动回滚已成功的命令 127.0.0.1:6379 MULTI OK 127.0.0.1:6379 SET key1 value1 # 会成功 QUEUED 127.0.0.1:6379 INCR key1 # 会失败 QUEUED 127.0.0.1:6379 SET key2 value2 # 会成功 QUEUED 127.0.0.1:6379 EXEC 1) OK 2) (error) ERR value is not an integer or out of range 3) OK # key2仍然被设置了不支持条件判断不能在事务中根据前一个命令的结果决定是否执行后续命令127.0.0.1:6379 MULTI OK 127.0.0.1:6379 GET balance QUEUED # 这里无法判断balance是否足够然后决定是否执行DECR 127.0.0.1:6379 DECR balance QUEUED 127.0.0.1:6379 EXECLua 脚本 - 更好的选择由于事务的局限性Redis 推荐使用Lua 脚本来实现复杂的原子操作Lua 脚本示例# 扣减库存的Lua脚本 EVAL local stock redis.call(GET, KEYS[1]) if stock and tonumber(stock) tonumber(ARGV[1]) then redis.call(DECRBY, KEYS[1], ARGV[1]) redis.call(LPUSH, KEYS[2], ARGV[2]) return SUCCESS else return INSUFFICIENT_STOCK end 2 product:1001:stock orders 1 order123Lua 脚本的优势真正的原子性支持复杂逻辑减少网络开销避免竞态条件实际应用建议适合使用事务的场景需要一次性执行多个相关命令对一致性要求不是极端严格命令之间没有复杂的条件依赖不适合使用事务的场景需要真正的回滚机制命令执行依赖于前一个命令的结果对一致性要求极高最佳实践# 1. 简单操作使用事务 MULTI SET key1 value1 SET key2 value2 EXEC # 2. 需要条件判断的使用Lua脚本 EVAL if redis.call(GET, KEYS[1]) then ... end 1 key # 3. 需要乐观锁的使用 WATCH WATCH key MULTI # ... 命令 EXEC总结Redis 事务的核心特点批量执行一次性执行多个命令串行化执行期间不会被其他命令打断无回滚遇到错误继续执行不会回滚乐观锁通过 WATCH 实现简单的并发控制记住关键点Redis 事务不是真正的ACID事务主要用途是批量执行和简单乐观锁复杂场景推荐使用 Lua 脚本WATCH 事务 可以实现简单的并发控制理解了这些你就能正确地使用 Redis 事务了