建议收藏！dockerentrypoint环境变量

一、

前些年，互联网行业里对架构师这个岗位的标准还不是很清晰。所以，很多架构师的工作往往就是一些技术被公司认可的资深工程师负责。

彼时，正巧我也是这类人员之一，故也得到了一个从零开始架设一套广告投放平台的机会。

我很喜欢钻研技术，对这种机会自然很看重。

那时候，架构并无如今这么复杂，一开始就是前面搞几个 Web 应用，后面共享个数据库。大致像这样：

当然，上面的架构其实做了很多简化，省略了很多细节。比如，为了提高性能做的缓存，为了提高吞吐做的负载均衡统统没有在上图给出。因为这些和本章话题无关，暂时咱们就忽略这些东西，只看核心部分。

这套架构初期运行还是没什么问题的，再加上一些缓存机制，初期一些性能问题都通过调整缓存提升缓存的碰撞率应付了过去。

可是，随着广告投放量的增大，广告的访问量也在暴涨。这些暴涨的访问量引发了性能问题。当时，由于前端有负载均衡，应用层倒是没出现什么问题……

问题出在后面的数据库上

二、

这套架构数据库用的是 MySQL，本身也只有一台主库在对外服务，另外一台备库采用了 MySQL 自己的全同步机制做实时备份。

当广告访问量暴涨的时候，因为业务需要，很多数据需要在数据库中做实时插入，这就导致了大量的磁盘 IO 产生。这些大量的磁盘 IO 造成了数据库本身性能的急剧下降。

悲催的是，整套广告平台的所有功能又都是共享一个数据库的，所以随着数据库本身的性能下降，平台的所有功能都受到了影响。

由于问题主要在于大量广告流量的写入，所以，靠读写分离的方案去缓解问题这条路就走不通了。

只好先升级硬件了。在经过了几轮硬件升级和数据库调优之后，单数据库再也无法支撑不断上涨的流量了。没办法，要考虑搞数据库切分了。

那时候，我个人是很恐惧数据库切分的。

原因不仅仅在于需要在应用层多写很多复杂的逻辑，其根本原因是当时流行的 2PC（两阶段提交）方案，这个方案本身能保证在数据库切分的情况下，原来的事务依然保留着自身的 ACID 性质。即:

1. Atomicity（原子性），不管事务里执行多少命令，对外它们都是一体的，要么都执行，要么都不执