8个可能限制系统扩展能力的瓶颈
极客时间编辑部
讲述：丁婵大小：2.18M时长：04:46
近日，公众号阿飞的博客编译了企业家肖恩·赫尔（Sean Hull）的文章，文中列出一些最可能限制系统扩展能力的瓶颈。除了监控指标不足、日志不足、内存不足、缺乏文档、缺乏故障演练、串行处理以及技术债等问题，还有一些问题需要开发者警惕。本文精选了 8 个可能限制系统扩展能力的瓶颈，以供开发者参考。
1. 二阶提交
通常当数据库中的数据有变化时，它会被写入本地服务器的内存和磁盘中。但是，当数据库是集群或者分布式系统的话，一个提交不仅会发生在本地，还会发生在远程。二阶提交意味着必须等待远程服务确认。然后由于网络和其他的延迟问题，这样的提交相比单机数据库的提交要慢很多。
主从的同步复制也有这样的问题，因此，MySQL 的解决办法是半同步。半同步只需要等待 slave 写成功日志响应即可，并不需要等待 slave 完成真正的提交。这实际上是二阶提交的妥协。
2. 数据库单点
你的数据库至少应该有一个 slave，它的好处是当 master 出现问题后，slave 能够顶上，更快恢复数据库从而提供服务。哪怕你的 slave 不承担读的压力，你也应该有一个冷备份的 slave。
3. 把数据库当作队列
MySQL 数据库很擅长存储关系型的表数据，不幸的是，它不太擅长作为队列服务。然而很多开发者还是会无形中把数据库表当作队列来使用，最终遇到可伸缩性问题等等。如果有队列方面的需求，更推荐使用 RabbitMQ 或者 Kafka。
4. 使用数据库全文检索
对任何一个应用来说，搜索都是非常重要的功能。尽管 MySQL 有全文检索功能，但是它的前提是表，必须是 MyISAM 引擎。然而 MyISAM 表没有事务特性，而且它的性能和体验都非常差。
成熟的方案都会借助于专业的搜索服务，而且这些专业的搜索服务客户端支持非常多的语言，访问速度也快，弹性伸缩能力也很好。
5. ORM
ORM 有助于快速原型设计，并允许那些不擅长 SQL 的开发人员读写数据库。它们更快、更干净，并提供更快的功能交付。
当 DBA 发现一个运行缓慢的 SQL，并要你的团队修复时，你会发现使用 ORM 框架的话，排查问题是非常困难的。但是，对于开发人员来说，排查并优化问题 SQL 是经常要做的事情。如果你的项目使用的是 ORM，就会带来巨大的技术债，而且替换的代价也非常大。所以建议项目使用 MyBatis 这样的框架。
6. 没有仪表盘
汽车如果没有仪表盘，你将没办法开车。同样的，如果你的应用没有仪表盘，也会带来很多阻碍。应用仪表盘能够暴露应用程序内部工作的信息，它们记录时间并提供有关应用程序花费时间的反馈。
一个非常流行的 Web 服务仪表盘解决方案是 New Relic，它提供了吸引所有人的可视化仪表板，项目经理、开发人员、运营团队甚至业务部门都可以在图表中查看。
7. 没有代码仓库或者版本控制
如果你不用版本控制和代码仓库，那么当你的项目越来越复杂时，欠下的技术债就会越来越多，最终导致整个迭代举步维艰。
8. 预览模式缺失
如果你尝试在头条上发表评论，或者在微信上发送一条朋友圈动态。你可能会收到这样的提示信息：“对不起，请稍后再试！”。或者你在淘宝上只能预览商品，但是不能下单。
这种现象就是指，应用允许你读，但不允许你写。这可能是 master 库宕机了，但是 slave 库还健在。你的系统需要具备这种能力，当 master 库宕机后，slave 能正常的处理读取操作，只是写操作暂时受到影响。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
- sagasw串行，应该读作行为的行，而不是行业的读音。1
收起评论