aajjw的博客

分布式事务分布式与事务横跨不同服务器，由多个本地事务组成如无必要，不要引入分布式事务分布式事务的典型场景跨JVM进程：微服务，通过业务补偿解决自动的补偿机制就是分布式事务。。。跨数据库实例：一个应用调用了多个库，不应该出现这样的情况，应该通过服务调用数据库做了拆分，处于不同的数据库实例中尽量避免这样的拆分，通过绑定表这样的形式，比如订单库，都通过订单ID分片但是客户级的处理就无法避免了解决方案数据库维度和服务维度两阶段提交XA 协议

分布式系统集中式一台或多台计算机组成中心节点，数据集中存储在这个中心节点中，整个系统的所有业务集中部署在这个中心节点中，系统所有动能均由其集中处理。什么是分布式系统在分布式系统概念和设计一书中定义：分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此间仅通过消息传递进行通信和协调的系统特性分布性：每一台计算机分布在不同的地方对等性：分布式系统中的计算机没有主/从之分，组成分布式系统的所有节点都是对等的。并发性：同一个分布式系统的多个节点，可能会并发地操作一些共享的资源，诸如

面向服务的架构要点通信通信协议：基于tcp或者http通信序列化：二进制，json等同步or异步rpc或者rest服务注册发现从ip地址直连到服务注册中心解耦服务管控负载均衡限流，降级，熔断服务监控上下线，优雅停机发布：A/B发布，灰度发布分布式链路跟踪其他日志分析api与测试开发注意参数验证异常处理dubbo2特性dubbo2是rpc+服务管控支持多种序列化协议：dubbo，rest，http，hessian，grpc等

结论前置a. redis分布式锁并不可靠，但是性能高。ⅰ. 本质上是因为其追求高性能而牺牲了可靠性ⅱ. 应用CAP原理解释就是redis是一个AP系统，强调了高可用性而牺牲一部分一致性，导致了redis分布式锁不可靠b. 追求可靠性应使用zk分布式锁，但是性能不如redis。redis分布式锁的各种实现方案及优缺点分析a. 自己实现redis分布式锁ⅰ. 加锁只用key加锁。问题：A加的锁，B能解。所以需要key value一起加锁，解锁时判断value是不是自己先get，若不存在，再s.

Raft的前世今生因为Paxos优秀而并不完美，Raft继承Paxos优点，改进缺点。Paxos优点：实现了安全性（safety）与存活性(liveness), 且在正常的情况下， 效率不差。Paxos缺点：难以理解和缺失了工程化的细节信息Raft目标安全性： 算法正确性能得到证明， 确保多状态机一致性的达成存活性： 半数以上结点正常工作且相互能够通信的情况下， 整个系统能持续对外提供服务易懂性： 聪明的你和我都能快速理解 Raft 协议的核心原理与正确性易实现： 充分描述算法的实现细

Multi Paxos是什么Basic Paxos 只能对一个值形成决议，决议的形成至少需要两次网络来回，在高并发情况下可能需要更多的网络来回，极端情况下甚至可能形成活锁实际应用中我们常常需要连续确定多个值，而且希望能有更高的效率。补充分布式一致性协议，来源于我们对系统可用性，容错性的追求。 为了避免单机失效导致整个系统不可用的问题， 我们会很自然地希望复制数据多结点部署。 但数据一旦出现了多份， 就需要解决一致性的问题。为了解决多份数据的一致性问题， 我们常常将其简化为多份状态机的一致性问

paxos算法是什么在容忍消息乱序、重复、少数派宕机的前提下，多个节点就一个值达成一致，不管这个值是什么。这里的“一致”隐含意思的最终一致性，即如果所有节点存活且可达，在经过一定的时间后，最终所有节点的值会一致。这种算法统称为consensus algorithm（翻译为共识算法或者一致性算法）。世界上只有一种一致性算法，那就是paxos，其他的都是残次品。paxos算法简述组成proposal：提案，提案包括proposal number：提案编号和value：提案内容。proposer：用来