aoe2022-05-19一次只做一件事这个原则非常实用，是一个解决遗留系统的神器！ 当初接到了优化赠送礼物接口的任务（四种不同的场景，功能各有千秋，就像火锅的四种不同锅底，没人关心底料的配方，好吃就行）： 1. 第一次（一年前）信心满满的尝试分析所有场景，准备抽取公共部分。结果只提取了一小段，没有功能测试做保障，改不动； 2. 第二次（现在）由于业务量增加，频出问题，简单粗暴的选择了出问题最多的那个场景进行改造，虽然仍旧复杂，但看的到希望，不像第一次被众多的功能压垮 3. 今天学习了老师的文章才明白：这就是一次只做一件事的威力！作者回复: 感谢分享。 其实像第一次，分析出所有场景并没有问题，但落地的时候，还是先要将这些场景做拆分，按优先级一个一个来。
4
chon2022-05-25老师请教一下，数据拆分有一个场景就是由于数据量大了，需要分库分表。貌似如何拆分数据这章节没提到怎么做。是不是也是和异构数据库的套路一样？如果讨论是一样的话，有没有什么和异构数据库不一样，需要特别注意的地方？作者回复: 分库分表是一个技术性场景，我在这个专栏里主要专注的是基于业务的拆分。分库分表的思路和异构数据库还不太一样，推荐你学习一下李玥老师的课程，有一讲是专门讲分库分表的（https://time.geekbang.org/column/article/217568），同时也可以在极客时间搜索一下，这方面的内容有很多。
子夜枯灯2022-05-13报到，报道。老师拆分数据库后的事物问题，如何处理？拆分Schema，基于原有数据表上横向拆分和纵向拆分有哪些优缺点需要提前规划呢？作者回复: 事务问题推荐通过消息机制用最终一致性解决；拆库横向拆和纵向拆的目的是不同的，横向是拆关系，纵向是拆大小，看你需要的是什么。
实习工程师
2022-10-12 来自广东第三步，同时写入新旧两个库，但只从新库中读数据。当我们对新库的基础设施有了信心之后，就可以把读操作也转移到新库中。这时我们仍然双写数据，因此出现任何问题都可以回退。1- 实习工程师2022-10-12 来自广东第三步，同时写入新旧两个库，但只从新库中读数据。当我们对新库的基础设施有了信心之后，就可以把读操作也转移到新库中。这时我们仍然双写数据，因此出现任何问题都可以回退。 老师， 这里好像有点不通畅， 应该是先读旧库，对新库有信心了再切换读新库？
雨落～紫竹2022-07-04当需求量上来后 这些都只能是技术债了