程序员去广告被索赔100万元 网友算了笔账
|
这样按照业务模块拆分之后，相应的 trade 数据库被拆分到了三个 RDS 实例中，数据库的写入能力提升，服务的接口响应时间也变短了，提高了系统的稳定性。 按表分库 上面介绍了分表方案，常见的有垂直分表和水平分表(拆分后的子表都在同一个 RDS 实例中存储)，对应的分库就是垂直分库和水平分库，这里的分库其实是拆分 RDS 实例，是将拆分后的子表存储在不同的 RDS 实例中，垂直分库实际业务用的很少，就不介绍了，主要介绍下水平分库。
举个例子，交易数据库的订单表 orders 有2亿多数据，RDS 实例遇到了写入瓶颈，普通的 insert 都需要50ms，时常也会收到 CPU 使用率告警，这时就要考虑分库了。根据业务量增长趋势，计划扩容一台同配置的RDS实例，将订单表 orders 拆分20个子表，每个 RDS 实例10个。 从执行计划可以看到，通过分区键user_id过滤，直接可以定位到数据所在的分区 p19(user_id =1019 % 20 = 19，所以在p19分区上)，进而去访问p19对应的数据文件 ordersp19.ibd 即可获得数据。这种方案的好处就是 MySQL 内部实现 SQL 路由的功能，不用去改造业务代码。 分库方案 聊了下分表的方案，那什么时候分库呢?我们知道，MySQL 的高可用架构大多都是一主多从，所有写入操作都发生在 Master 上，随着业务的增长，数据量的增加，很多接口响应时间变得很长，经常出现 Timeout，而且通过升级 MySQL 实例配置已经无法解决问题了，这时候就要分库，通常有两种做法：按业务拆库和按表分库，下面就介绍这两种分库方案啦。 按业务分库
举个例子，交易系统 trade 数据库单独部署在一台 RDS 实例，现在交易需求及功能越来越多，订单，价格及库存相关的表增长很快，部分接口的耗时增加，同时有大量的慢查询告警，升级 RDS 配置效果不大，这时候就需要考虑拆分业务，将库存，价格相关的接口独立出来。 这样就将 orders 表拆分成20个子表，对应到InnoDB的存储上就是20个数据文件(orders_0.ibd，orders_1.ibd等)，这时候执行SQL语句select order_id, order_sn, source from **orders** where user_id = 1001;就能很快的定位到要查找记录的位置是在orders_1，然后做查询重写，转化为SQL语句select order_id, order_sn, source from **orders_01** where user_id = 1001，这种查询重写功能很多中间件都已经实现了，常用的就是 sharding-sphere 或者 sharding-jdbc 都可以实现。 按月分表
对于账务或者计费类系统，每天晚上都会做前一天的日结或日账任务，每月的1号都会做月结或月账任务，任务执行完之后相关表的数据都已静态化了(业务层不需要这些数据)，根据业务的特性，可以按月创建表，比如对于账单表 bills，就可以创建按月分表(十月份表bills_202010，202011十一月份表)，出完月账任务之后，就可以归档到历史库了，用于数据仓库ETL来做分析报表，确认数据都同步到历史库之后就可以删除这些表释放空间。 在 《Clean Code》 中列举了一些常见注释坏味道：
为什么过多的注释是一种代码坏味道呢? 好的注释可以辅助开发人员快速阅读理解代码，过多的注释或坏注释可能会降低代码的可读性。 在开发实践中经常有同学修改了代码但是注释没有同步修改，代码的实现已经与注释内容不一致，容易产生误导。 如何解决过多的注释这种坏味道呢? (1)如果代码块不再使用请直接删除不要使用注释。 (2)方法、变量的命名尽量见名知意，避免用注释再解释一遍。 (3)如果较短的注释不能覆盖方法的含义，可能是这个方法职责不单一，可以考虑重构这个方法。 总结：
文章列举了几种比较常见的代码坏味道，希望大家在工作编码中多多练习，争取人人都能写出好代码，让天下没有难读的代码。 （编辑：孝感站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
