MQ+HashMap原理+事务四大特性+Redis三种部署方式

什么叫消息队列

消息（Message）是指在应用间传送的数据。消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。
消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，由消息系统来确保消息的可靠传递。消息发布者只管把消息发布到 MQ 中而不用管谁来取，消息使用者只管从 MQ 中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。

为何用消息队列

从上面的描述中可以看出消息队列是一种应用间的异步协作机制，那什么时候需要使用 MQ 呢？
以常见的订单系统为例，用户点击【下单】按钮之后的业务逻辑可能包括：扣减库存、生成相应单据、发红包、发短信通知。在业务发展初期这些逻辑可能放在一起同步执行，随着业务的发展订单量增长，需要提升系统服务的性能，这时可以将一些不需要立即生效的操作拆分出来异步执行，比如发放红包、发短信通知等。这种场景下就可以用 MQ ，在下单的主流程（比如扣减库存、生成相应单据）完成之后发送一条消息到 MQ 让主流程快速完结，而由另外的单独线程拉取MQ的消息（或者由 MQ 推送消息），当发现 MQ 中有发红包或发短信之类的消息时，执行相应的业务逻辑。
以上是用于业务解耦的情况，其它常见场景包括最终一致性、广播、错峰流控等等。

MQ解决什么问题（应用场景）

MQ是一直存在,不过随着微服务架构的流行,成了解决微服务之间问题的常用工具

1、应用解耦

以电商应用为例,应用中有订单系统、库存系统、物流系统、支付系统,用户创建订单后,如果耦合调用库存系统、物流系统、支付系统,任何一个子系统出了故障,都会造成下单操作异常。
当转变成基于消息队列的方式后,系统间调用的问题会减少很多,比如物流系统因为发生故障,需要几分钟来修复,在这几分钟的时间里,物流系统要处理的内存被缓存在消息队列中,用户的下单操作可以正常完成,当物流系统恢复后,继续处理订单信息即可,中单用户感受不到物流系统的故障,提升系统的可用性

2、流量消峰

如果订单系统最多能处理一万次订单,这个处理能力应付正常时段的下单时绰绰有余,正常时段我们下单一秒后就能返回结果,但是在高峰期,如果有两万次下单操作系统是处理不了的,只能限制订单超过一万后不允许用户下单。
使用消息队列做缓冲,我们可以取消这个限制,把一秒内下的订单分散成一段时间来处理,这事有些用户可能在下单十几秒后才能收到下单成功的操作,但是比不能下单的体验要好

3、消息分发

多个服务队数据感兴趣，只需要监听同一类消息即可处理。
例如A产生数据，B对数据感兴趣。如果没有消息的队列A每次处理完需要调用一下B服务，过了一段时间C对数据也感性，A就需要改代码，调用B服务，调用C服务，只要有服务需要，A服务都要改动代码，很不方便。
有了消息队列后，A只管发送一次消息，B对消息感兴趣，只需要监听消息，C感兴趣，C也去监听消息，A服务作为基础服务完全不需要有改动。

4、异步通知

有些服务间调用是异步的，例如A调用B，B需要花费很长时间执行，但是A需要知道B什么时候可以执行完，以前一般有两种方式，A过一段时间去调用B的查询api查询，或者A提供一个callback api，B执行完之后调用api通知A服务，这两种方式都不是很优雅。
使用消息总线，可以很方便解决这个问题，A调用B服务后，只需要监听B处理完成的消息，当B处理完成后，会发送一条消息给MQ，MQ会将此消息转发给A服务（监听此消息），这样A服务既不用循环调用B的查询api，也不用提供callback api，同样B服务也不用做这些操作，A服务还能及时的得到异步处理成功的消息

电商系统中的RabbitMQ的使用（异步通知场景）

电商系统简单分为：订单系统和支付系统。当用户下单后需要进行支付，支付成功这笔订单才算完成了，那我如何知道用户什么时候支付完成呢？这时就用到了RabbitMQ消息队列。当用户在支付时，支付系统会发送消息到MQ，消息中含有是否支付成功等等信息，而订单系统会实时监听该消息队列，一旦接收到该消息，会对其进行信息分析，比如是否支付成功了，由此来改变订单的状态，比如从未支付改为已支付状态。

HashMap的put()和get()的实现

1、map.put(k,v)实现原理

第一步首先将k,v封装到Node对象当中（节点）。第二步它的底层会调用K的hashCode()方法得出hash值。第三步通过哈希表函数/哈希算法，将hash值转换成数组的下标，下标位置上如果没有任何元素，就把Node添加到这个位置上。如果说下标对应的位置上有链表。此时，就会拿着k和链表上每个节点的k进行equal。如果所有的equals方法返回都是false，那么这个新的节点将被添加到链表的末尾。如其中有一个equals返回了true，那么这个节点的value将会被覆盖。

2、map.get(k)实现原理

第一步：先调用k的hashCode()方法得出哈希值，并通过哈希算法转换成数组的下标。第二步：通过上一步哈希算法转换成数组的下标之后，在通过数组下标快速定位到某个位置上。重点理解如果这个位置上什么都没有，则返回null。如果这个位置上有单向链表，那么它就会拿着参数K和单向链表上的每一个节点的K进行equals，如果所有equals方法都返回false，则get方法返回null。如果其中一个节点的K和参数K进行equals返回true，那么此时该节点的value就是我们要找的value了，get方法最终返回这个要找的value。

3、为何随机增删、查询效率都很高的原因是？

原因：增删是在链表上完成的，而查询只需扫描部分，则效率高。

事务四大特征ACID:

 1、原子性：每个事务都属于最小操作单元，要么全部成功，要么全部失败。

 2、一致性：数据库总是从一个一致性的状态转换到另一个一致性的状态。例如，即使取钱操作失败，因为事务没有提交，所以事务 ，所做的修改也不会保存到数据库中，数据还是事务执行前的状态。如果事务执行成功，那数据就是执行后的状态，保持不变。

 3、持久性：事务一旦提交，对数据库的更改操作就是持久的。

 4、隔离性：多个事务并发执行，彼此独立互不干扰。

      未提交读（脏读）：A B 同时操作一份数据，A读到B尚未提交的记录。例如B将数据从库里的1累加到10，B事务完成数据库  最终值为10，未提交读隔离级别使得A能读到B从1-10累加过程中的中间数据。

      提交度（不可重复读）：A 只能读到B提交后的数据。也就是说A只能读到原纪录1或B累加操作事务提交后的10，不会读到B操作的中间数据。

      可重复读（幻读）：

      串行化：事务严格按照一定顺序串行。 

Redis三种部署方式

standaloan(单机模式)

standaloan 是redis单机模式，及所有服务连接一台redis服务，该模式不适用生产。如果发生宕机，内存爆炸，就可能导致所有连接改redis的服务发生缓存失效引起雪崩。

sentinel（哨兵模式）

redis-Sentinel(哨兵模式)是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行切换

redis-cluster(集群模式)

redis集群模式，同样可以实现redis高可用部署,Redis Sentinel集群模式中，随着业务量和数据量增，到性能达到redis单节点瓶颈，垂直扩容受机器限制，水平扩容涉及对应用的影响以及数据迁移中数据丢失风险。针对这些痛点
Redis3.0推出cluster分布式集群方案，当遇到单节点内存，并发，流量瓶颈是，采用cluster方案实现负载均衡，cluster方案主要解决分片问题，即把整个数据按照规则分成多个子集存储在多个不同几点上，每个节点负责自己整个数据的一部分。
Redis Cluster采用哈希分区规则中的虚拟槽分区。虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合，整数定义为槽（slot）。Redis Cluster槽的范围是0 ～ 16383。槽是集群内数据管理和迁移的基本单位。采用大范围的槽的主要目的是为了方便数据的拆分和集群的扩展，每个节点负责一定数量的槽。Redis Cluster采用虚拟槽分区，所有的键根据哈希函数映射到0 ～ 16383，计算公式：slot = CRC16(key)&16383。每一个实节点负责维护一部分槽以及槽所映射的键值数据。下图展现一个五个节点构成的集群，每个节点平均大约负责3276个槽，以及通过计算公式映射到对应节点的对应槽的过程。