1. 项目背景与核心挑战家用智能充电桩后台系统面临三大核心挑战首先是数据量激增问题单个充电桩每天产生约1.4万条状态记录按1秒/次上报百万级设备规模下每日新增数据量可达140亿条其次是业务复杂度高需要同时处理设备管理、充电控制、订单支付等异构业务最后是系统可用性要求充电桩作为家庭基础设施需要保证7×24小时稳定服务。我在实际架构设计中采用了微服务分库分表的组合方案。SpringBoot微服务架构解决业务解耦问题将系统拆分为六个核心服务模块。而MySQL分库分表则针对性地解决了海量数据存储和查询性能问题这个方案在实测中成功支撑了单库5000万设备数据的稳定运行。2. 架构设计核心思路2.1 垂直拆分业务解耦之道垂直分库按照业务领域进行划分每个微服务对应独立的数据库实例。这种设计带来三个显著优势故障隔离单个数据库故障不会影响其他业务比如订单库出现问题时设备管理仍可正常运行性能优化可以为不同业务配置专属的MySQL参数如充电记录库的innodb_buffer_pool_size可以设置更大团队协作各微服务团队可以独立进行数据库变更和优化我们在生产环境中的具体拆分方案如下权限中心(charge_auth)独立部署包含用户、角色等基础权限数据设备中心(charge_device)部署在专属高IOPS SSD存储上应对频繁的设备状态写入充电服务(charge_service)使用读写分离架构主库负责写入多个只读副本处理实时查询2.2 水平拆分大数据量应对方案对于单表数据量可能过亿的核心业务表采用水平分表策略。这里需要特别说明分片键选择的考量设备ID(user_id/device_id)作为分片键的优势数据本地性同一设备的所有数据落在同一分片避免跨分片查询查询效率90%的查询都带有设备ID条件可以直接路由到特定分片扩容简便采用一致性哈希算法扩容时只需迁移部分数据按时间分片的适用场景日志类数据具有明显的时间局部性特征方便实现冷热数据分离近期数据保留在MySQL历史数据归档到数据仓库符合业务查询模式如查询某设备上月充电记录3. 分库分表详细实现3.1 数据库规范设计所有分库遵循统一的规范设计这是保证系统可维护性的关键-- 统一使用utf8mb4字符集支持emoji -- 所有表必须包含的公共字段 CREATE TABLE template_table ( id bigint NOT NULL COMMENT 雪花ID, tenant_id bigint DEFAULT 0 COMMENT 租户ID, creator bigint COMMENT 创建人, create_date datetime(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3), updater bigint COMMENT 更新人, update_date datetime(3) ON UPDATE CURRENT_TIMESTAMP(3), is_delete tinyint unsigned DEFAULT 0 COMMENT 逻辑删除, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;字段设计要点主键使用雪花ID而非自增ID避免分库分表时的ID冲突时间字段精确到毫秒(datetime(3))方便问题排查和排序逻辑删除字段统一命名(is_delete)保持业务逻辑一致性3.2 水平分表的具体实现以充电记录表为例展示水平分表的完整实现方案-- 分表命名规则业务前缀_sharding_分片号(00-63) CREATE TABLE cr_charge_record_sharding_00 ( id bigint NOT NULL, device_id varchar(64) NOT NULL COMMENT 分片键必须建索引, user_id bigint NOT NULL, -- 其他业务字段... PRIMARY KEY (id), KEY idx_device_id (device_id), -- 分片键索引 KEY idx_user_id (user_id), KEY idx_create_date (create_date) ) ENGINEInnoDB; -- 分片路由算法示例Java实现 public class ShardingAlgorithm { // 一致性哈希分片计算 public static int calculateShard(String deviceId, int shardCount) { int hash deviceId.hashCode() 0x7FFFFFFF; // 取正数 return hash % shardCount; } }分片策略实践经验分片数建议取2的整数幂如64方便后续扩容每个分片建议控制在500万-1000万行数据超过应考虑增加分片数避免使用UUID作为分片键会导致数据分布不均3.3 全局表同步机制对于字典表等需要全局一致的数据采用以下同步方案-- 在权限中心库定义全局表 CREATE TABLE sys_dict_type ( -- 字段定义... ) ENGINEInnoDB; -- 在其他库创建相同结构的表 CREATE TABLE sys_dict_type ( -- 字段定义与主库完全一致 ) ENGINEInnoDB; -- 使用Canal监听binlog实现准实时同步同步方案选型对比方案实时性复杂度适用场景分布式事务强一致高关键配置数据定时任务分钟级中非关键数据binlog同步秒级较高大多数场景4. 业务适配与优化4.1 充电桩业务特色设计针对家用充电桩场景我们在权限体系上做了特殊扩展-- 用户表新增设备相关字段 ALTER TABLE sys_user ADD COLUMN default_device_id varchar(64) COMMENT 默认充电设备; ALTER TABLE sys_user ADD COLUMN charge_notify tinyint DEFAULT 1 COMMENT 充电通知开关; -- 角色表新增设备权限类型 ALTER TABLE sys_role ADD COLUMN device_perm varchar(500) COMMENT 设备权限标识;业务适配要点用户-设备绑定关系采用逻辑外键避免跨库JOIN充电状态变更记录设备ID和时间戳方便问题追踪为家庭用户设计简化的权限模型降低使用复杂度4.2 性能优化实践在分库分表基础上我们还实施了以下优化措施索引优化方案联合索引设计(device_id, create_date) 覆盖主要查询场景前缀索引对长文本字段如address只索引前20个字符定期使用pt-index-usage工具分析索引使用情况查询优化示例-- 不好的写法会导致全分片扫描 SELECT * FROM charge_record WHERE user_id 123; -- 优化写法带上分片键条件 SELECT * FROM charge_record WHERE device_id IN (SELECT device_id FROM user_device WHERE user_id 123) AND create_date 2023-01-01;5. 踩坑经验与解决方案5.1 分布式事务难题在订单支付场景下需要跨充电服务和订单库更新数据。我们最终采用的方案是// 使用Seata的AT模式 GlobalTransactional public void completeCharge(Long recordId) { chargeService.updateStatus(recordId, Status.COMPLETED); orderService.finishOrder(recordId); paymentService.confirmPayment(recordId); }分布式事务选型建议优先考虑最终一致性方案如本地消息表对强一致性场景使用Seata AT模式避免跨库事务尽量通过设计规避5.2 分页查询优化分库分表环境下的分页查询是个经典难题。我们的解决方案是-- 使用分片键时间范围缩小查询范围 SELECT * FROM charge_record_sharding_* WHERE device_id DEV123 AND create_date BETWEEN 2023-01-01 AND 2023-01-31 ORDER BY create_date DESC LIMIT 20 OFFSET 0;分页优化技巧禁止使用不带分片键条件的LIMIT查询大数据量分页改用上一页/下一页模式使用Elasticsearch构建二级索引支持复杂查询5.3 数据迁移实践系统上线后需要进行历史数据迁移我们总结的最佳实践是使用阿里云DTS工具实现不停机迁移迁移前先建立好所有分表结构采用分批迁移策略先迁最近3个月热数据迁移完成后进行数据校验确保一致性6. 监控与运维体系完善的监控是分库分表系统稳定运行的保障关键监控指标分片数据量分布均衡性单分片查询响应时间跨分片查询比例分布式事务成功率我们使用PrometheusGrafana构建的监控看板包含以下关键面板分片数据量热力图直观展示各分片数据分布慢查询统计按微服务分类展示TOP50慢SQL连接池监控跟踪各库连接使用情况7. 未来演进方向随着业务发展我们规划了以下优化方向混合存储架构将冷数据自动归档到TiDB等分布式数据库智能分片基于机器学习预测数据增长趋势动态调整分片策略多租户优化为大型物业公司提供专属分片保证服务质量这个分库分表方案在实际运行中取得了显著效果在500万活跃设备规模下核心接口响应时间保持在200ms以内数据库CPU利用率长期低于40%。最重要的是这套架构为后续业务扩展提供了充足的空间新业务模块可以通过新增微服务和分库快速接入。