幸福城市平台：数据库选型与优化实践

随着外面平台和外卖行业的兴起，越来越多的企业开始涉足本地化的外卖、配送、跑腿等业务，目前市场基本是美团和饿了么的天下，但是在一些三线城市领域，存在着最本土化的本地电商平台-幸福城市，幸福城市不是一个平台，是N多个三线城市各自的品牌，只是使用了同一套技术平台。幸福城市平台开发公司在构建应用程序时，采用了经典的前端+服务+数据库的系统架构，服务比较成熟，使用java编写。但是在数据库领域面对一个核心问题：如何选择合适的数据库。本文将以国内提供幸福城市平台的软件开发公司为例，详细介绍我公司如何根据自身需求进行数据库选型，以及在面对性能瓶颈时如何进行优化。

一、背景介绍

幸福城市平台是一个为市民提供便捷生活服务的软件平台，涵盖外卖、跑腿、团购、教育、医疗、交通、环保等多个领域。该平台通过收集和分析城市数据，为政府决策提供支持，同时也为市民提供更为精准和个性化的服务。在平台开发的初期，我公司选择了***数据库作为数据存储和处理的核心。

二、从***到MySQL：成本考量

然而，随着平台用户数量的增加，***数据库的版权费用和使用成本变得越来越高。为了降低运营成本，我公司决定转向开源的MySQL数据库。MySQL的开源特性使得我公司可以免去版权费用，降低服务器成本，同时也降低了部署和维护的成本。

三、MySQL扩展性问题

但是，随着平台的持续发展和数据量的急剧增加，MySQL的扩展性问题逐渐凸显出来。尽管MySQL在数据处理能力上有一定优势，但在处理大规模数据时，其性能瓶颈和扩展性问题难以得到解决。这导致了数据库响应速度变慢，平台性能下降，严重影响了用户体验。平台每日产生0.5GB的数据，mysql的动态扩容也给系统运维工程师提出了挑战。

四、从MySQL到TiDB：优化与升级

面对MySQL的扩展性问题，我公司开始寻找新的数据库解决方案。经过一系列的性能测试和对比，最终选择了TiDB作为新的数据库系统。TiDB是一个开源的分布式数据库，具有强大的扩展性和高性能。它采用了分布式架构，可以轻松地处理大规模数据，解决了MySQL在扩展性方面的问题。

五、TiDB的优势与挑战

TiDB的分布式架构使得数据可以分散存储在不同的节点上，提高了数据处理能力和响应速度。同时，TiDB支持水平扩展，可以根据需求增加节点数量以提高数据处理能力。此外，TiDB还提供了丰富的数据一致性保障和容错机制，确保了数据的安全性和可靠性。

然而，转向TiDB也带来了一些挑战。首先，由于TiDB的分布式特性，部署和维护相对较为复杂。其次，TiDB的学习曲线较陡，开发人员需要熟悉分布式数据库的原理和操作。最后，TiDB虽然解决了扩展性问题，但在某些特定场景下，其性能可能不如单节点数据库。

六、部署与实施

1、经过计算和分析，我公司决定按照官方建议部署多节点高可用的架构，以下是配置信息

服务配置数量tidb-server16C48G SAS磁盘200G4pd-server8C16G ***磁盘200G3tikv-server 16C48G64G ***1.7TB*5动态增加7监控8C16G SAS磁盘200G1

由于不涉及在线数据分析，所以不部署tiflash

2、在数据备份上，运维人员使用传统的Br备份模式，在稳定运行半年时间后，运维人员对数据备份策略进行提升，加入Ticdc，并实现读写分离，通过业务上的主从架构实现数据库的高可用，并在从库上进行数据备份操作，升级后架构变为

服务配置数量tidb-server16C48G SAS磁盘200G4pd-server8C16G ***磁盘200G3tikv-server16C48G64G ***1.7TB*5动态增加7监控8C16G SAS磁盘200G1ticdc16C64G ***磁盘3Tb1从库和主库配置相同1

3、目前数据库已经上线一年时间，性能和扩展性以及高可用特性都可以满足系统需求。

七、优化与改进：幸福城市平台的未来方向

1、为了解决TiDB面临的挑战，我公司采取了一系列优化措施。首先，我们组织内部培训和学习活动，帮助开发人员熟悉TiDB的操作和原理。其次，我们优化了数据库部署策略，根据平台的业务需求和流量模式进行节点设置和资源配置。第三，我们持续监控数据库性能，定期进行性能测试和优化调整。最后，我们计划和tidb厂家合作，寻求厂家的技术支持，为数据库稳定运行保驾护航。

2、在tikv存储上，通过优化系统磁盘，节约了近70%的硬件成本，每年为公司节约了数百万元，以下是磁盘的优化方案

***提供了一种独享的本地ssd磁盘服务器，本地盘是ECS实例所在物理机上的本地硬盘设备。本地盘能够为ECS实例提供本地存储访问能力，具有低时延、高随机IOPS、高吞吐量和高性价比的优势。

性能测试： 执行命令 fio -group_reporting -thread -name=iops_test -rw=randwrite -direct=1 -size=8G -numjobs=8 -ioengine=psync -bs=4k -ramp_time=10 -randseed=0 -runtime=60 -time_based 说明：bs=4k：IOPS 测试将每次 IO 写入的单元量设置为 4k，因为 *** 的 page 一般大于等于 4k，设置这个值尽可能地增加 IOPS 的结果 direct=1：绕过操作系统的 buffer cache，以获取真实的 IO 效果 numjobs=8：同时创建8个同样的任务进行测试，一般8个任务就能吃满 IO 资源 iodepth=1：默认使用 psync 引擎因此队列深度大于1没有意义

测试结果： write: IOPS=103k, BW=403MiB/s (422MB/s)(23.6GiB/60001msec)

成本： 同样配置 16 vCPU 64 GiB内存 2T nvme磁盘 1870.8/月 如果全部换成该磁盘成本： 1870.8712=157,147.2元/年 每年节省成本510652.8-157147.2=353505.6元/年 每年节省成本69.2%

为什么性能优势那么大一般都不使用： 如下是***原文写的缺点： 警告 使用本地盘存储数据有丢失数据的风险，例如ECS实例所在物理机发生硬件故障时。请勿在本地盘上存储需要长期保存的业务数据。 建议您在应用层做数据冗余，保证数据的可用性。您可以使用部署集将业务涉及到的几台ECS实例分散部署在不同的物理服务器上，保证业务的高可用性和底层容灾能力。具体操作，请参见创建部署集。 如果您的应用无数据可靠性架构设计，强烈建议您在ECS实例中同时使用云盘或者备份服务，提高数据可靠性。更多信息，请参见云盘概述或什么是混合云备份HBR。

我们使用的TIDB 是一个分布式事务型的键值数据库，提供了满足 ACID 约束的分布式事务接口，并且通过 Raft 协议保证了多副本数据一致性以及高可用。如果某台服务器出现故障可以凭借TIDB的三副本策略恢复损坏的副本。

替换磁盘技术方案：

TIDB提供了 tiup cluster scale-out 命令用于集群扩容，扩容的内部逻辑与部署类似，tiup-cluster 组件会先建立新节点的 SSH 连接，在目标节点上创建必要的目录，然后执行部署并且启动服务。其中 PD 节点的扩容会通过 join 方式加入到集群中，并且会更新与 PD 有关联的服务的配置；其他服务直接启动加入到集群中。 语法 tiup cluster scale-out <topology.yaml> [flags]  为要操作的集群名字，如果忘记集群名字可通过集群列表查看 <topology.yaml> 为事先编写好的扩容拓扑文件，该文件应当仅包含扩容部分的拓扑

下线特殊处理 由于 TiKV，TiFlash 和 TiDB Binlog 组件的下线是异步的（需要先通过 API 执行移除操作）并且下线过程耗时较长（需要持续观察节点是否已经下线成功），所以对 TiKV，TiFlash 和 TiDB Binlog 组件做了特殊处理： 对 TiKV，TiFlash 及 TiDB Binlog 组件的操作: tiup-cluster 通过 API 将其下线后直接退出而不等待下线完成 执行 tiup cluster display 查看下线节点的状态，等待其状态变为 Tombstone 执行 tiup cluster prune 命令清理 Tombstone 节点，该命令会执行以下操作： 停止已经下线掉的节点的服务 清理已经下线掉的节点的相关数据文件 更新集群的拓扑，移除已经下线掉的节点 对其他组件的操作 o下线 PD 组件时，会通过 API 将指定节点从集群中删除掉（这个过程很快），然后停掉指定 PD 的服务并且清除该节点的相关数据文件 o下线其他组件时，直接停止并且清除节点的相关数据文件

通过这些优化措施，幸福城市平台成功解决了数据库扩展性问题，极大的降低了数据库成本，提高了平台的性能和用户体验。未来，我公司将继续关注数据库技术的发展趋势，根据业务需求进行技术升级和优化调整，为市民提供更为便捷和高效的生活服务。

八、结论：数据库选型的重要性与优化策略

幸福城市平台的案例充分说明了数据库选型对于软件开发的重要性。一个合适的数据库可以极大地提高应用程序的性能和用户体验。在面对不同需求时，软件开发公司应根据业务特点、数据量、预算等因素综合考虑选择合适的数据库系统。

在优化数据库性能方面，可以采取以下策略：定期性能测试、优化部署策略、合理配置资源、关注数据库技术发展动态等。同时，公司还应注重培训和更新开发人员的技能储备，以应对不断变化的数据库技术趋势。