架构师第四周

用户头像
Tulane
关注
发布于: 2020 年 07 月 01 日

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



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

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

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



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

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



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

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

用户头像

Tulane

关注

还未添加个人签名 2018.09.18 加入

还未添加个人简介

评论

发布
暂无评论
架构师第四周