进了一家强制 996 的公司，略有体会。在 IT 行业，特别是开发岗位，总避免不了加班。以前工作也时常有加班，还会有封闭开发，但这些加班总会有个期限，有个项目完成结束加班的盼头，但 996 不是，无尽头。
业务驱动的 996 ，个人认为也有某些好处，但只对刚毕业的，新手、才入行、开发经验低于 3 年的工程师有效，可以通过较多的工作时长接触更多的业务和模块，了解学习项目中已有的技术栈，达到快速理解业务，快速实现业务功能，技术快速成长成型。
若是一个经过好几个项目历练的，经验相对丰富、自我驱动成长的开发工程师，业务驱动的 996 与之存在必然的矛盾。
接下来可能就变成了老白兔、老油条、专属的螺丝钉。
Web 系统的表单重复提交问题必然会出现，如注册、秒杀下单、支付等场景都可能出现重复提交。必须对重复提交进行处理，否则会出现脏数据，若建了唯一索引则会抛 JDBC 异常。单体应用的表单重复提交问题可参考 拦截器 与Spring AOP 实现防止表单重复提交。
分布式集群部署的 Web 做防止表单重复提交的处理上，其根本也是基于 TOKEN 的方式来实现，因是集群布署，所以此 TOKEN 不能存放在 SESSION 中(未使用共享 SESSION 方案) ，而是存放在外部存储系统中，如 Reids，这里其实引入了类似分布式锁的概念。
微服务之注册中心 Zookeeper 与 Eureka 比较
分布式环境的一个非常重要的理论是 CAP 原则，即一个分布式系统不可能同时满足 C（一致性）、A（可用性） 和 P（分区容错）。而分区容错是分布式架构中必须要保证的，因此只能在 A 与 C 之间进行权衡。
Zookeeper 保证的是 CP ， 而 Eureka 保证的则是 AP。
分布式架构中通常都会存在共享资源，在多个服务或一个服务多个实例同时对此共享资源进行读写操作情况下，会存在数据不一致性，就需要分布式锁来解决此问题。
实现分布式锁通常会借助外部组件，主要有四种实现方式，基于 Redis 实现，基于 Zookeeper 实现，直接使用 Redisson 已实现的分布式锁，Google 的 Chubby 服务。
本地事件表加消息队列实现分布式事件方案实现数据的最终一致性。本地事件表作用是为了事件溯源（Event-Sourcing），消息队列实现事件通知。
事件表要求记录了业务表操作的所有事件，所有事件的组合就是表中数据的生命周期。
本篇是 分布式微服务应用系列(九)：分布式事务概念及解决方案 的延续。
今天下载安装了一个款软件，安装完后，在桌面莫名其妙的多了一个 IE 的图标，并且无法删除，打开后直接进入一个网址导航的站点，都 Windows 10 了，谁还用 IE，超级恶心。
解决办法：
微服务分布式架构中的分布式事务是一个技术难点，为了保证数据的一致的，必须要解决分布式事务问题。
分布式事务的两个基本理论是 CAP 和 BASE，为实现分布式解决方案提供了理论方向。实现分布式事务的解决方案主要有两种类型，一种是基于强一致性协议实现，另一种是柔性事务实现数据最终一致性。
本篇是上篇 数据结构与算法(三)：树 和 二叉树 的延续。
二叉堆 是一种特殊的堆，本质上是一种完全二叉树。二叉堆有两个类型：最大堆 和 最小堆。
优先队列中，元素被赋予优先级。当访问元素时，具有最高优先级的元素最先删除。优先队列具有最高级先出 （first in, largest out）的行为特征。通常采用堆数据结构来实现。
有些数据的逻辑关系并不是简单的线性关系，常常存在一对多，甚至多对多的情况。例如，一个家族的 “家谱”，企业的职级关系等、书本的目录章节等都可以用树型数据结构来描述。
树 和 图 是典型的非线性数据结构。本篇描述对 树 和 二叉树 的理解。
栈 和 队列 也是常见的数据结构。Java 里面的方法栈，消息队列 是 栈 和 队列 数据结构的实际应用。