标签：最大 分布式锁 clu 修改 宕机 线程 消息中间件 nio setnx
（1）token令牌的生成
通过token替代session，session有个最大的问题是不支持集群。把token存在redis里，因为redis是可以共享使用的。
（2）短信验证码code
验证码有效期只有30分钟或者1小时，使用redis对验证码的code设置有效期。
（3）使用redis去减轻数据库访问的压力
把热点数据（经常被查询到的）做成热点key。热点key要提前预热下（提前把热点的key从数据库放到redis中，否则刚开始访问的用户直接从数据库中查询，速度很慢）。
（4）网页计数器
记录网页的PV量多少。redis是单线程的，可以保证线程安全，保证原子性。
（5）分布式锁
redis中实现分布式锁有两种方案：a. setnx；b.使用框架。
（6）订单30分钟有效期
使用redis的key的有效期和失效的监听。一旦key失效时，会走客户端的一个回调，告诉客户端一个事件通知。
（7）实现注册中心、分布式的配置中心等
redis是线程安全的。redis是单线程的。
redis数据都存在内存里面的。核心是用到nio的io多路复用机制（ngix），能够很好支持并发，从而保证线程安全。
redis单线程，也就是底层采用一个线程去为维护多个不同客户端的io操作。
但是nio在不同操作系统实现机制不同。在windows中使用select实现轮询的时间复杂度是o(n)，而且还存在空轮询的情况，效率很低，其次是默认对轮询的数据有一定的限制，所以吃出上万的tcp连接很难。
所以在linux上采用epoll实现事件驱动回调，不会存在空轮询的情况，只对活跃的连接实现主动回调，这样性能大幅度提升，，而是时间复杂度为o(1)。这就是为什么ngix和redis都能支持很高程度的并发，最终都是linux的io多路复用机制epoll。
（redis官方不支持windows版本，windows里是没有epoll）
io多路复用是nio。服务器端只用一个线程去维护客户端所有连接。请求（tcp连接）通过管道（Channel）到达服务器都会注册到一个选择器（selector）的集合中去，通过一个线程去循环遍历这个集合，判断每个连接是否有数据，有数据就读取。（一个线程去维护所有客户端连接）。----》这就是io多路复用。（多路：多个连接。复用：用一个线程去维护）
io多路复用有三个核心区域：管道channel、选择器selector和缓冲区buffer。为什么用到buffer：因为字节流传输效率很低，通过缓冲，成块成块的传输，提高效率。
redis使用到io多路复用原则，即redis通过一个选择器去接受客户端的所有请求，一个线程不断循环判断里面是否有数据，有数据就开始读取。
方法一：存放json
string类型，存json就行，再通过json反序列化对象。好处：？
方法二：存放二进制
不跨语言，只支持java对象。
支持。两种形式：Multi和Watch。
redis中的事务和mysql中事务的区别：redis中的事务默认是没有行锁机制：mysql中一个事务中对某行数据进行操作，在另一个事务中就不能对这行数据进行操作（行锁）；而redis多个事务可以对同一个key进行操作，没有行锁机制，很难保证数据的原子性（缺陷）。
上面是Multi的缺陷，通过Watch解决。
watch原理是采用redis的乐观锁机制（版本号）控制。每次set时版本号加1，当提交事务时和set时版本号如果不一致（证明中间有其他事务对这个key修改了），就会提交失败。
watch可以监视一个或多个键，一旦在接下来的一个事务执行之前有一个键值发生了改变，那么事务就不会被执行。注意：是接下来的一个事务，而不是所有事务。
redis中事务不支持回滚，只是支持事务的取消。redis为什么不支持回滚？mysql回滚把行锁给释放掉，redis中没有行锁，就不用回滚了。
有。redis发布订阅一般很少用。数据一致性就是通过发布订阅去订阅到数据库的binlog去保持和数据库的数据一致。
搞一个token30分钟，当token失效时，会走客户端的回调方法，再检测下订单有没有支付，没有支付就返回超时。
（1）直接清空redis，重新读取数据库。问题是效率不高。
（2）采用增量binlog的同步方案。在redis和数据库之间有个消息中间件，消息中间件订阅到数据库的binlog文件（订阅的过程），一旦客户端对数据库有增删改操作时，binlog文件就会增加，消息中间件就会订阅过来，消息中间件再把这些增量的binlog发给redis，redis解析binlog文件，然后再去操作。
（1）对内存实现扩容
（2）淘汰策略：把不经常使用的key释放掉。
不会。redis会持久化到硬盘中（最多延迟1秒的数据）。rdb和aof（增量同步，以日志方式写入aof中）。
注意：开启了aof持久化最多丢失1秒的数据。（redis中数据，数据库还有。redis不会当数据库用）
rdb和aof。
区别：rdb属于全量同步，把所有数据生成二进制文件，放到硬盘中。好处是效率高，缺陷是有定时性，丢失数据多。aof属于增量同步，表示把每个增删改操作记录到aof日志文件中，aof有三种方式：每秒钟同步一次；每次操作都同步；从不同步（缓冲区满了就os自动同步），默认是每秒钟同步一次。优点是最多只会丢失一秒的数据，缺点是效率低。
增量是对行为同步：每次增删改操作都会同步到日志文件中
全量采用定时同步：每隔多长时间同步一次。
redis 主 同步数据给 从 时产生延迟，问题：会出现脏读或者数据不一致。（redis集群都是内网搭的，也很少存在延迟。服务器跨区域会存在）。redis很难保证强一致性，数据同步时网络存在时间差（集群都有这个问题）。只能人工补偿，或者人工手动把数据迁过来。只能最终一致性的方案实现数据的同步。
采用多主多从或者树状结构去实现同步。一主多从（哨兵）时，主的同步压力很大，要给其他从发送同步的数据命令，主宕机了就无法写操作。因此要做多主多从（cluster集群），是个树状形式。哨兵是一主多从，是中心化思想集群，而多主多从是去中心化。
高可用？？主从同步中如果主宕机了，那么就要人为的从从redis中选一个节点出来做主节点，效率低，就引入哨兵机制。哨兵解决的问题就是当主节点宕机情况下，自动的从剩余的节点选出一个新的主节点。哨兵也需要集群部署（有几个redis就有几个哨兵），因为要投票保证公平性。哨兵如何确定主宕机了？配置文件里面配置有几个哨兵确认主宕机之后，才会认为master宕机了，然后从新选。
缺陷：哨兵安装了多个；只能有一个主节点，不能存在多个；这种集群缺陷是数据可能产生冗余（主和从的数据保持一致，非常浪费资源）。因此引入redis的cluster集群
cluster集群是分片集群。预先会分配16384个卡槽，会根据算法？对key计算卡槽对应在哪个服务器位置，然后直接做个set操作。优点是：实现快速的扩容和缩容，而且是去中心化的，可以存在多个master节点。
标签：最大 分布式锁 clu 修改 宕机 线程 消息中间件 nio setnx
原文地址：https://www.cnblogs.com/yq055783/p/13043724.html
