Java 注解（Annotation）是 JDK 1.5 引入的特性，与类、接口、枚举是在同一等级。它可以作用在类、属性、方法、局部变量、方法参数上，用于对这些元素进行说明，注释，解释。

注解在功能上可以看成是一个接口，注解实例就是一个实现该接口的动态代理类，可在方便在程序运行期间通过反射获取该字段或方法的注解的实例，来决定下一步如何处理。

本篇描述 Sharding-JDBC 分片相关概念，了解相关概念有助于理解 Sharding-JDBC 的使用和配置方式，更好地在项目中应用，有问题时更容易的排查和定位。

Sharding-JDBC 相关概念包有：分片方式包括水平分片和垂直分片；分片算法包括常见的范围分片，取模分片，Hash分片，时间分片等；分表涉及到逻辑表，真实表，绑定表，广播表；基于 Spring Boot Starter 框架使用的行表达式。

此系列文章都是基于 Sharding-JDBC 4.x版本， 在写此文章时，正式发布的是 4.1.0版本，点此 4.x 官方文档。

Sharding-JDBC 已经是一款非常流行、轻量级、易用的客户端侧的数据库中间件。更多认识 Sarding-JDBC 可参考 深度认识 Sharding-JDBC：做最轻量级的数据库中间层 。

Sharding-JDBC 最初是当当自研的数据库中间件，后在开源社区推广流行，后被推荐到 Apache 孵化更名为 Apache ShardingSphere。

此系列文章都是基于 Sharding-JDBC 4.x版本， 在写此文章时，正式发布的是 4.1.0版本，点此 4.x 官方文档。

创建型模式 之 简单工厂模式、工厂方法模式、抽象工厂模式。

工厂模式是比较常见，应用较为广泛的模式，工厂模式主要用于创建对象，把对象的创建和使用进行分离。

本篇对这三种工厂模式进行描述和对比分析。

设计模式(Design Pattern) 为面向对象设计中反复出现的问题提供解决方案。

设计模式是对使用 面向对象程序语言 进行 面向对象设计 而总结的方法论，代表了最佳实践，可以使得程序更具 扩展性、易于修改，易于复用。

设计模式（GOF 23 种） 根据使用目的分为三大类，分别是 创建型模式、结构型模式、行为型模式，每类又可细分为两个子类，分别对应类 和 对象。

要理解 设计模式，前提是必须深入理解面向对象的三个基本特征：封装，继承、多态。有的把 抽象 也作为面向对象的基本特征，抽象严格来讲应归属于 继承。另外就是还需要对 高内聚、低耦合 略有体会。

此系列是个人对设计模式的理解 和 Java 实现 Demo 的汇总，同时也参考了大量网上的资料或博文，在此表示感谢。

强列推荐闫宏的《Java 与 模式》，2002年出的书，大师出品，怎么看都不会过时，非常非常好，强烈推荐三次都不为过，看过该本书后我才对何为好书，何为经典的书有了基本概念，特别是基础理论类的书，经典的书经久不衰。

遗憾的是该书没有新版印刷，但网上可以下载到电子版的。也看过其它设计模式相关的书，开发经验略丰富点的就会感觉到没落地，代码不典型，与实际脱节。

进了一家强制 996 的公司，略有体会。在 IT 行业，特别是开发岗位，总避免不了加班。以前工作也时常有加班，还会有封闭开发，但这些加班总会有个期限，有个项目完成结束加班的盼头，但 996 不是，无尽头。

业务驱动的 996 ，个人认为也有某些好处，但只对刚毕业的，新手、才入行、开发经验低于 3 年的工程师有效，可以通过较多的工作时长接触更多的业务和模块，了解学习项目中已有的技术栈，达到快速理解业务，快速实现业务功能，技术快速成长成型。

若是一个经过好几个项目历练的，经验相对丰富、自我驱动成长的开发工程师，业务驱动的 996 与之存在必然的矛盾。

1. 项目及项目结构已成型，大量的时间消耗在无止境的 CRUD 需求中。
2. 特别是技术型人才，自我驱动需要绝对的闲余时间来保证学习的持续性。
3. 996 上班，到家过了 10 点，洗洗歇歇就很晚了，不管工作中有是否忙或闲，在公司总待了那么长时间，到家总需要放松歇下。然后第二天仍是重复的工作。
4. 若是一个已成家有孩子的，一周也就周日一天时间在家可以陪陪，真正有时间用时学习成长上的少之又少。

接下来可能就变成了老白兔、老油条、专属的螺丝钉。

Web 系统的表单重复提交问题必然会出现，如注册、秒杀下单、支付等场景都可能出现重复提交。必须对重复提交进行处理，否则会出现脏数据，若建了唯一索引则会抛 JDBC 异常。单体应用的表单重复提交问题可参考 拦截器 与Spring AOP 实现防止表单重复提交。

分布式集群部署的 Web 做防止表单重复提交的处理上，其根本也是基于 TOKEN 的方式来实现，因是集群布署，所以此 TOKEN 不能存放在 SESSION 中(未使用共享 SESSION 方案) ，而是存放在外部存储系统中，如 Reids，这里其实引入了类似分布式锁的概念。

分布式环境的一个非常重要的理论是 CAP 原则，即一个分布式系统不可能同时满足 C（一致性）、A（可用性） 和 P（分区容错）。而分区容错是分布式架构中必须要保证的，因此只能在 A 与 C 之间进行权衡。

Zookeeper 保证的是 CP ， 而 Eureka 保证的则是 AP。

分布式架构中通常都会存在共享资源，在多个服务或一个服务多个实例同时对此共享资源进行读写操作情况下，会存在数据不一致性，就需要分布式锁来解决此问题。　　

实现分布式锁通常会借助外部组件，主要有四种实现方式，基于 Redis 实现，基于 Zookeeper 实现，直接使用 Redisson 已实现的分布式锁，Google 的 Chubby 服务。

本地事件表加消息队列实现分布式事件方案实现数据的最终一致性。本地事件表作用是为了事件溯源（Event-Sourcing），消息队列实现事件通知。

事件表要求记录了业务表操作的所有事件，所有事件的组合就是表中数据的生命周期。

本篇是 分布式微服务应用系列(九)：分布式事务概念及解决方案 的延续。