努力分享一些干货

—大意：简而言之，微服务体系结构风格是一种将单个应用程序开发为一套小型服务的方法，每个服务运行在自己的进程中，并与轻量级机制(通常是HTTP资源API)通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。对这些服务的集中管理是最低限度的，这些服务可能用不同的编程语言编写，并使用不同的数据存储技术。

它管理数据一致性，防止多个节点同时修改相同数据，处理资源竞争，保障事务原子性，避免任务重复执行，同时协调和同步节点操作，减少死锁的可能性。例如，在表中记录锁的创建时间，并定期检查是否超时，如果超时则自动释放锁。只有在比自己序号小的节点被删除后，才会再次检查自己是否成为最小的节点，进而获取锁。利用顺序节点实现锁的公平性，保证了锁的获取顺序。，查出来的数据是相同的，然后依次执行库存减一操作，此时库存会变成-1件，这就造成了超卖问题。当释放锁时，节点会检查锁的持有者是否匹配，只有匹配的情况下才会删除锁。

在分库之后， 数据遍布在不同服务器上的数据库，数据库的自增主键已经没办法满足生成的主键唯一了，这个时候就需要生成分布式。适用于并发不高，但是数据量太大导致的分库分表扩容，可能每秒最高并发最多就几百，那么就走单独的一个库和表生成自增主键即可。雪花算法相对来说还是比较靠谱的，毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的，能达到百万计。生成，如果是高并发啥的，那么用这个应该性能比较好，一般每秒几万并发的场景，也足够用了。

当微服务系统的一个服务出现故障时，故障会沿着服务的调用链路在系统中疯狂蔓延，最终导致整个微服务系统的瘫痪，这就是“雪崩效应”。为了防止此类事件的发生，微服务架构引入了“断路器”的一系列服务容错和保护机制。

—大意：简而言之，微服务体系结构风格是一种将单个应用程序开发为一套小型服务的方法，每个服务运行在自己的进程中，并与轻量级机制(通常是HTTP资源API)通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。对这些服务的集中管理是最低限度的，这些服务可能用不同的编程语言编写，并使用不同的数据存储技术。

其中AP在实际应用中比较多，AP舍弃一致性，保证可用性和分区容忍性，但是在实际生产中很多场景都要实现一致性，比如主数据库向从数据库同步数据，即使不要一致性，但是最终也要将数据同步成功来保证数据一致，这种一致性和CAP中的一致性不同。例子中形成了一个事务，若张三或李四其中一人拒绝付款，或者钱不够，老板都不会出票，并且把已收的钱退回。整个事务过程由事务管理器和参与者组成，老板就是事务管理器，张三、李四就是事务参与者，事务管理器负责抉择整个分布式事务的提交和回滚，事务参与者负责自己的本地事务提交和回滚。