dump（转储）
canal 就像mysql主从复制的从机一样 监听主机的二进制文件（小抄） 有改动 抄作业到自己小抄上 在滕在试卷上 双写一致性要求 Redis有数据要和mysql保持一致 Redis无数据 mysql的数据一定要是最新的。 同步直写：小数据，某条，某一小撮热点数据、要求立马变更，可以前台服务降级一下，后台服务马上直写。#################################异步缓写：canal出现异常后，不得不将失败的动作重新修补，不得不借助kafka或兔子mq等消息中间件，实现解耦后重试重写。 更新策略 先mysql后Redis这种有三种 第一种先更新数据库在更新缓存会出现问题 Redis如果异常更新失败会出现脏读操作企业里（使用二三） 第二种先删除缓存再更新数据库 （还是有问题 多线程下删掉了并更新数据库新值 第二个线程快 1刚删完读旧值 读完后又把旧值写回了Redis）---------大厂：延时双删策略（删除 更新 空格两秒多久都行再删 （没有最好，有的话删掉以后再度直接写新值进Redis）） 第三种先更新数据库在删除缓存（有问题 读的线程快 读的旧值）相当于死信队列 删除失败后存到mq kafka 在发回来删除 Redis 底层io多路复用 多个socket通过epoll监听存入 epoll 存入队列 队列通过文件分发器 ---- 多路复用模型 四个重要概念 （同步阻塞）服务让你等 你原地杵（同步非阻塞）服务让你等着牛刷会抖音 (异步阻塞)服务员让你逛逛你原地杵（异步非阻塞）服务员让你等着 你刷会抖音 这个效率最高 BIO阻塞在 accept和read 所以一次只能一个客户端发送信息 （堵塞在read了） 解决办法 用线程包裹住read 这样就阻塞在socket的创建那里 来一个我连一个 问题也来了 太耗资源了啊 使用线程池？？？少的话还行 多的话 分配多大？so
NIO（非阻塞IO模型）（accept 和read都不阻塞） 事件驱动型IO实际就是IO多路复用不要被唬住了 select就解决了bio循环等值 散弹枪的命中率 变成了狙击枪 epoll谁有数据我扒拉谁 所谓的reactor反应模式 Redis的select就是把java的代码内核态成c了 更快减少用户态和内核态之间的切换cpu提升 select 查的是bitmap中的1 表示学生要交卷了 so一次select（一个班主任）+N个read select有两个问题poll解决了头两个 so epoll 课外 为何Redis和Nginx运行在linux上快 能调用linux底层函数