线程安全的List
获取线程安全的List我们可以通过Vector、Collections.synchronizedList()方法和CopyOnWriteArrayList三种方式
读多写少的情况下，推荐使用CopyOnWriteArrayList方式
读少写多的情况下，推荐使用Collections.synchronizedList()的方式
使用这种方法我们可以获得线程安全的List容器，它和Vector的区别在于它采用了同步代码块实现线程间的同步。通过分析源码，它的底层使用了新的容器包装原始的List。
下图是新容器的继承关系图：
- 普通集群：
- 以两个节点（rabbit01、rabbit02）为例来进行说明。rabbit01和rabbit02两个节点仅有相同的元数据，即队列的结构，但消息实体只存在于其中一个节点rabbit01（或者rabbit02）中。
- 当消息进入rabbit01节点的Queue后，consumer从rabbit02节点消费时，RabbitMQ会临时在rabbit01、rabbit02间进行消息传输，把A中的消息实体取出并经过B发送给consumer。所以consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连rabbit01或rabbit02，出口总在rabbit01，会产生瓶颈。当rabbit01节点故障后，rabbit02节点无法取到rabbit01节点中还未消费的消息实体。如果做了消息持久化，那么得等rabbit01节点恢复，然后才可被消费；如果没有持久化的话，就会产生消息丢失的现象。
- 镜像集群：
- 在普通集群的基础上，把需要的队列做成镜像队列，消息实体会主动在镜像节点间同步，而不是在客户端取数据时临时拉取，也就是说多少节点消息就会备份多少份。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用
- 由于镜像队列之间消息自动同步，且内部有选举master机制，即使master节点宕机也不会影响整个集群的使用，达到去中心化的目的，从而有效的防止消息丢失及服务不可用等问题
kafka高性能的原因
- Broker NIO异步消息处理，实现了IO线程与业务线程分离；
- 磁盘顺序写；
- 零拷贝（跳过用户缓冲区的拷贝，建立一个磁盘空间和内存的直接映射，数据不再复制到用户态缓冲区）；
- 分区/分段（每次文件操作都是对一个小文件的操作，非常轻便，同时也增加了并行处理能力）；
- 批量发送 (可以指定缓存的消息达到某个量的时候就发出去，或者缓存了固定的时间后就发送出去，大大减少服务端的I/O次数)
- 数据压缩
2pc 3pc 的区别，解决了哪些问题
3pc 将2pc中的一阶段拆为 canCommit和prepareCommit
二阶段提交有几个缺点：
-
同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。
二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
- 3pc比2pc 减少事务阻塞范围 。3pc在超时后会自动提交。相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。
Zookeeper watch机制原理。
- 客户端注册Watcher到服务端;
- 服务端发生数据变更;
- 服务端通知客户端数据变更;
- 客户端回调Watcher处理变更应对逻辑;