秒杀系统的架构设计
秒杀系统，是典型的短时大量突然访问类问题。优化思路：
- 写入内存而不是写入硬盘（SSD硬盘比传统硬盘的读写性能快100倍，内存比ssd快10倍）
- 异步处理而不是同步处理（用户请求写入内存立刻返回。后台启动多个线程从内存池中异步读取数据，进行处理）
| 后台启动多个线程 | 项目中经常会有后台运行任务的需求，比如发送邮件时，因为要链接邮件服务器，往往需要5-10秒甚至更长时间，如果能先给用户一个成功的提示信息，然后在后台慢慢处理发送邮件的操作，显然会有更好的用户体验。利用异步处理，通常用消息队列MQ来实现，而redis可以看做是一个高性能的MQ，因为它的数据读写都发生在内存中。 |
|---|
- 分布式处理
MYSQL的秒杀
使用mysql实现秒杀，实现原理是加锁，当多个用户同时对一个字段进行修改时，给数据加锁。只有当事务提交或回滚才会释放锁。for update(加锁)只能放到select中，只有当查询时把数据锁住才有意义。
BEGIN;
INSERT INTO stock_log VALUES
select count from aa where id=1 and count>0 for update;
update bb set count=count-1 where id=1 and count>0;
COMMIT;
mysql事务并发，虽然相比串行，提高了数据库资源利用率，提高了数据库系统的事务吞吐量，从而可以支持更多的用户。
但是会带来一系列问题：更新丢失，脏读，不可重复读，幻读。
防止更新丢失，并不能单靠数据库事务控制器解决，需要应用程序对要更新的数据加必要的锁来解决，因此防止更新丢失应该是应用的责任。
脏读，不可重复读，幻读其实都是数据库读一致性问题，必须有数据库提供一定的事务隔离机制来解决。
事务隔离级别：
RR RC RUC RS
https://blog.csdn.net/lida1234567/article/details/82866617
数据类型redis使用场景
string
- 计数器应用
list
- 取最新N个数据的操作
- 消息队列
- 删除与过滤
- 实时分析正在发生的情况，用于数据统计与防止垃圾邮件（结合set）
set
- unique操作，获取某段时间所有数据排重值
- 实时系统，反垃圾系统
- 共同好友、二度好友
- 利用唯一性，可以统计访问网站的所有独立IP
- 好友推荐的时候，根据tag求交集，大于某个threshold就可以推荐
hashes - 存储读取修改用户属性
sorted set - 排行榜应用，取top N操作
- 需要精准设定过期时间的应用（时间戳）
- 带有权重的元素，比如一个游戏的用户得分排行榜
- 过期项目处理，按照时间排序
redis解决秒杀/抢红包等高并发事务活动
- 秒杀开始前30分钟把库存从数据库同步到redis sorted set
- 用户秒杀库存放入秒杀限制数长度的sorted set
- 秒杀到指定到秒杀数后，sorted set不在接收秒杀请求，并显示返回标识
- 秒杀活动完全结束后，同步redis数据到数据库，秒杀正式结束
队列
redis5beta版本新增stream处理队列，综合所有
https://www.jianshu.com/p/e5751c2ac9c8
https://www.jianshu.com/p/487ee7c3d337
FIFO（先进先出）队列，使用lpush、rpop即可实现一条FIFO队列
rpop消费最后一个元素的时候，无阻塞，这个线程将一直进行，单线程也会打满CPU
brpop移出并获取列表的最后一个元素，如果列表中没有元素会阻塞列表直到等待超时或发现可弹出的元素为止。
redis本身是一个单线程的程序（内存）,有天然的排它锁。
FIFO队列中的消息一经发送出去，便从队列里删除。如果由于网络原因消费者没有收到消息，或者消费者在处理这条消息的过程中崩溃了，就再也无法还原这条消息。FIFO队列不能保证消息会传递成功。
可靠队列
https://www.jianshu.com/p/544a2aeb0ca9
redis在rpoplpush的命令可以从一个list中获取消息的同时把这条消息复制到另一个list里面，并且这个过程是原子的
利用rpoplpush实现的可靠队列有两个列表组成，一个存储待处理pending的消息，另一个存储处理中processing的消息
生产者通过lpush将消息发送到pending列表
127.0.0.1:6379> LPUSH queue:pending "message"
消费者使用rpoplpush从待处理列表获取消息，同时将它加入处理中的列表
127.0.0.1:6379> RPOPLPUSH queue:pending queue:processing
"message"
此时这条消息在待处理列表删除，并且复制到处理列表中
127.0.0.1:6379> LRANGE queue:pending 0 -1
(empty list or set)
127.0.0.1:6379> LRANGE queue:processing 0 -1
1) "message"
消费者在收到消息或者处理完消息后，使用lrem命令从处理列表中删除这条消息，完成消息确认
127.0.0.1:6379> LREM queue:processing 1 "message"
使用lrem而不是rpop是因为，在并发时，不能保证处理中的消息能按加入列表的先后顺序被确认，而rpop会按照顺序删除消息
没有被确认的消息会一直存储在处理中列表，如果一个消息在处理中列表存在的时间过长，可以认为这个消息传递失败或处理失败，可以设定一个超时时间，定时扫描处理中的表，将超时的消息重新放回待处理列表等待重新传递。
延迟队列
https://www.jianshu.com/p/de41f7e080bc
