#秒杀技术重新梳理
##redis分布式锁
>首先要了解的乐观锁是什么？
>
数据库乐观锁，数据库增加一个版本标识
>redis乐观锁通过watch命令监视给定的key，当exec时候如果监视的key从调用watch后发生过变化，则整个事务失败。也可以调用watch多次监听
>多个Key。
>
>Redis事务是一组命令的集合。主要用到两个multi和exec命令。事务开始时向redis服务器发送multi命令，然后依次发送需要在本次事务中处理
>的命令
>1.multi，开启redis的事务
>2.exec，提交事务，执行从multi到此命令前的命令队列
>3.discard，取消事务
>4.watch，监视键值对
##rabbitmq与kafka的区别
- 为什么要使用消息队列
>解耦：将消息写入消息队列，需要消息的系统从消息队列中订阅
>异步：非必要的业务逻辑以异步方式进行，加快速度
>削峰：不直接访问数据库
- 消息队列的缺点
>系统可用性降低：消息队列可能会挂掉
>系统复杂性增加：加入了消息队列，要考虑一致性问题，如何保证消息不被重复消费，如何保证消息可靠性传输
- rabbitmq
>建议中小型公司使用，这种公司数据量不是很大，管理界面很方便，功能完善，社区活跃
- redis
>它的pub-sub模式是快产快消的的，全都是因为redis是使用内存来做存取，所有一旦被消费就会丢弃
>
>这样的场景可以考虑使用redis:对速度十分看重，允许出现消息丢失的场景，数据量不是很大，不需要保存消息
- kafka
>稳定，可以保存，不会丢失数据，速度不需要很快，需要处理的数据量很大，可以进行日志采集
- rocketMq
>是java语言开发的，和kafka一样支持分布式架构，可用性和单机吞吐量很高
- 消息不被重复消费（保证消息幂等性）
> 正常情况下，消费者在消费完毕时，会发送一个确认消息给消息队列，消息队列就知道消息被消费了，就会将该消息从消息队列中
>删除。不同的消息队列发出的确认消息形式不同，rabbitmq发送的是一个ack确认消息，rocketmq是返回的一个consume_success成功
>标志，kafka则是有个offet的概念。
>
>造成重复消息的原因是因为网络传输的故障导致确认消息没有传送到消息队列，导致消息队列不知道自己已经消费这个消息，会再次将
>这个消息发送给消费者
>
>解决的思路分为三种情况：第一个是你拿到这个消息做数据库的insert操作，给这个消息做一个唯一的主键；
>第二种情况比如你拿这个消息做redis的set操作，那么就不用操作，因为这个操作本身就是幂等的。
>第三种情况可以准备第三方的介质来做消费记录。拿redis举例，给消息分配一个全局id，只要是消费过该记录将<id,message>以k-v键值对的形式写入redis。在消费者开始消费
>消息之前，查看是否存在消费记录。
- 如何保证消费的可靠性传输
>换种说法就是保证消费不能丢失，无法做到可靠性传输会造成上千万损失？
>
>要保证可靠性传输需要从三个角度来考虑：第一是生产者弄丢了数据，第二是消息队列弄丢了数据，第三是消费者弄丢了数据
>
>第一种情况rabbitmq提供了transaction和confirm模式来确保生产者不会丢失消息
>transaction机制是说发送消息前，开启事务(channel.txSelect())，然后再发送消息，如果发送消息的过程中出现什么异常就回滚
>(channel.txRollback())，如果发送成功就提交事务。这种发送的一个缺点是吞吐量下降.
>一般使用的是confirm模式居多，所有在信道上发送的消息都会被指派一个唯一的id，一旦消息被投递到指定的消息队列中去就会发送一个
>ack给生产者，如果没有则发送nack给生产者
>
>第二种情况是持久化磁盘，具体是将queue的持久化标识durable设置为true，则代表是一个持久的队列，发送消息的时候讲deliveryMode=2
>
>第三是主要消费者采取的是自动确认消息模式？可以改成手动确定的模式，但是这样会造成消息重复消费的情况，主要是看guide的文章发现的
>下面评论的大神解决方案是手动维护偏移量，处理完业务逻辑在提交偏移量，为了保证不造成重复消费，可以将处理业务逻辑和提交偏移量绑定一个事务
>
##redis资源池必须及时关闭
