网站 被攻击主业篡改 被黑了 织梦做的站,网站开发视频教程百度云,网页设计与制作思政教学设计,wordpress 项目选项线程模型 纯内存操作/非阻塞io多路复用/单线程避免多线程频繁上下文切换 基于Reactor模式开发了网络事件处理器#xff1a;文件事件处理器#xff0c;单线程的 io多路监听多个socket#xff0c;据socket事件类型选择对应的处理器#xff0c;高性能网络通信模型#xff0c…线程模型 纯内存操作/非阻塞io多路复用/单线程避免多线程频繁上下文切换 基于Reactor模式开发了网络事件处理器文件事件处理器单线程的 io多路监听多个socket据socket事件类型选择对应的处理器高性能网络通信模型可其他单线程对接 简单性 文件事件处理器多个socket  io多路复用  文件事件分派器  事件处理器 io多路复用监听多个socket将socket放入队列排队每次从队列中取出socket给事件分派器给对应事件处理器处理完io多路复用将队列下一个socket给事件分派器 reactor synchronous event demultiplexer同步事件分离器监听各种事件调用方调用监听方法的时候会被阻塞 直到有事件发生 handler文件描述符简单理解一个一个事件  event handler事件处理器回调方法事件发生 据handler调用对应的回调方法  自己实现方法 步骤 高可用 主从 哨兵sentinel 集群监控 消息通知 故障转移 配置中心 redis cluster livu livechat中使用了 人家有槽slot 16384个呢 请求发送任意节点 该节点会将请求发送到正确节点上-相亲相爱 1.哈希的方式将数据分片 每个节点均分存储一定哈希槽区间的数据 2.每份数据分片会存储在多个互为主从的多节点上 3.先写主节点再同步从节点 4.读取数据当客户端操作的key没有分配在该节点返回转向指令指向正确节点 5.扩容时需要把旧节点的数据迁移一部分到新节点 6.每个redis放开两个端口6379 1637916379节点间通信cluster bus故障检测/转移 7.cluster bus用gossip二进制协议节点间高效数据交换占用更少的网络带宽和处理时间 优缺点谁还能没点缺 无中心架构支持动态扩容对业务透明 自备sentinel监控和自动failover故障转移能力 高性能直连redis服务 免去proxy损耗 有点缺人无完人 redis无完美  怎么说反正有缺点但是值得 运维复杂 数据迁移需要人工 只能使用0号数据库 不支持批量操作 分布式逻辑和存储模块耦合 redis sharding你可以不看  让我自己卷 多redis实例集群采用哈希算法将redis的key进行散列映射到特定的redis节点 简单服务端redis实例彼此独立相互无关联每个redis实例像单服务器一样 线性扩展 不支持动态删增节点服务器redis实例群拓扑结构变化每个客户更新调整 连接不共享  三大热门问题 还行 咱家项目设计稳稳当当 上学的时候遇到过一次 缓存穿透缓存 数据库都没有的数据库短时间内承受大量请求 接口层校验缓存取不到库中也没有可key-null 短的过期时间布隆过滤器bitmap中 缓存击穿缓存中没有库中有并发查同一条数据 热点永不过期互斥锁 缓存雪崩一瞬间大面积失效 设置随机过期时间/新增缓存标记是否失效/缓存预热/互斥锁 一致性 写不太频繁 1操作缓存 设置过期标识 客户端读缓存过期则休眠再查redis 2先删缓存看他不顺眼直接删了再写数据库休眠 再删缓存 主从同步 1 从节点slaveof masterip port 保存主节点信息 2 从节点定时任务发现主节点建立和主节点socket连接 3 从发送信号 主返回 互相私通 呸 互相私信连接建立 主all数据发送给从 runid每个redis节点启动生成唯一标识uuid offset主从各自维护自己的复制偏移量主也写offsetoffset命令字节长度从收到主发送命令后增加自己的offset把自己的offset发送给主节点主节点同时保存自己的offset和从的对比判断主从一致性数据 原理 repl_backlog_size主节点上固定长度的先进先出队列1M 复制 全量复制主节点bgsave命令fork子进程 rdb消耗cpu 内存 硬盘id主节点通网络rdb给从从清空老数据 载入rdb(阻塞)  部分复制执行复制的双方分别维护offset主内部维护固长 fifo复制积压缓存区队列主offset差距大过缓存区长度全量复制服务器runid 主把自己的runid发送给从 从存 从重连时 据runid判断同步进度 runid同之前同步过 主尝试部分复制 不同全量复制 事务ACISD 单线程  watch监控key的情况 1multi命令的执行(事务的开始)multi将客户端状态的flagsredis_multi 2命令multi/exec/watch/discard会立即执行否则将命令放入事务队列 客户端返回queue 其他命令 先检查格式 如果说来捣乱 服务器把客户端状态flags关闭redis_multi 返回错误 小黑屋了 队列说FIFO 先进先出讲规矩的队列 3执行 不支持回滚 watch乐观锁为redis提供check-and-set(cas)监控多个键有一个被修改则后面的事务不执行 监控持续到exec命令 multi开启事务执行后客户端可持续向服务器发送任意多条命令放入队列 exec被调 all命令执行 exec 执行事务块内命令按命令执行先后顺序排列操作被打断 返回空值null 调用discard客户端可清空事务队列放弃执行事务 unwatch取消watch对所有key对监控 分布式锁 setnxsetex 设置超时时间失败死锁 set(key,value,px)原子操作 redisson解决任务超时 锁自动释放 并发问题 数据结构 string list hash set sortedSet bitmap geohashsortedSet  hyperLogLog   streams 缓存过期策略 定期过期定时器清理 占大量CPU处理过期数据 缓存响应时间和吞吐量 惰性过期先判断是否过期过期删除节省CPU资源 消耗内存  定期过期每隔一段时间扫描一定数量的数据库中expires字典中一定数量的key 淘汰算法 fifo被存储时间 最远的先淘汰 LRU最近最少使用最近被使用的时间 LFU最不经常使用一段时间内 缓存被使用次数最少 缓存方案 客户端缓存页面 浏览器缓存 app h5 localStorage sessionStorage CND缓存内容存储  数据缓存  内容分发 负载均衡 nginx缓存静态资源 服务端缓存本地缓存 外部缓存 数据库缓存持久层缓存 mybatis。hibernate多级缓存 mysql查询 操作系统缓存page cache。 buffer  cache redis集群策略 主从主可写读和从数据同步主从宕 客户端手动修改ip  哨兵模式主库宕 哨兵从 从库选主 哨兵也可以集群 高可用 容量上的限制 cluster多主多从 按key进行槽位分配 不同key分散不同主节点上  持久化 save命令redis阻塞 直到rdb完成 bgsavefork子进程 主进程在fork过程中短暂阻塞子进程创建完主进程响应客户端请求 save m nm秒内n隔键改变 自动触发持久化 bgsave进行 设置多个满足其一就触发 flushall清空redis所有数据flushdb清空当前redis所在库数据(0号库 rdb文件) 主动同步全量同步自动触发bgsave命令 一个dump.rdb文件方便持久化 容灾性好 方便备份 性能最大化 fork子进程完成写操作  数据安全性低rdb间隔一段时间进行持久化redis故障数据丢失  aof亲这边建议优先使用 日志形式记录服务器处理的每一个写 删除操作 aof缓存区据策略向硬盘同步操作定期对aof文件重写 压缩的目的 每秒同步异步完成 效率高一秒数据会被丢失宕机时 每修改同步同步持久化每次发生数据变化 立即记录到磁盘 最多丢一条 不同步操作系统控制 丢失更多数据 数据安全redis-check-aof工具解决数据一致性问题 aof文件大 恢复慢 数据集大 rdb启动效率低运行效率无rdb高