架构师第四周

印象深刻的是老师讲的宅米网的一个例子, 说订单太大需要分库分表, 其实根据实际业务仅仅通过数据的冷热分离即可解决. 联系到在上一家公司的经历, 也是和此类似.



上家公司的一个项目在我入职那会儿达到快速增长期, 用户数突破8000万, 订单表数量更是上了3亿, 然而还是使用的MySQL, 性能已经是严重有缺陷.

当时的方案便是分库分表, 为此还重新重写了这个项目, 并创了个新库做分库分表后的库, 旧库等转移完毕就废弃.

由于数据量太大转移不是一时半会, 也不能长时间停机维护, 还需要做一个实时同步新旧库的项目, 总之这块改进成分库分表真是伤筋动骨, 现在想想是不是有更好的方案?



首先场景也和老师这块类似, 用户的订单其实并不重要, 事实是后面做了分表, 也有按每月分表, 那些之前月的表基本就是历史的尘埃无人问候.

本身超大的订单数据, 根据业务特性也可以舍弃掉, 做冷热分离, 旧的直接写进文件, 做这个改动不需要重写项目, 不需要迁移数据, 也不需要写特定的迁移项目, 只需要定时跑跑任务处理"过期"订单即可.



由此感悟到的是, 架构不是炫技, 架构的核心也不是用技术解决问题, 我觉得是用最有效最具性价比的方法, 解决当前及未来一段时间遇到的问题.

那这个问题的重中之重就是具体业务具体分析, 业界的那些成熟套路, 显得高大上又通用, 但每引入一个技术就增加了一层架构的复杂性, 不去剥离业务的解决问题, 最终会让问题越来越辣手.