tp5网站开发模板下载,宣城高端网站建设,哪个网站可以帮助做数学题,做气体检测仪的网站业务背景
北京科捷物流有限公司于2003年在北京正式成立#xff0c;是ISO质量管理体系认证企业、国家AAAAA级物流企业、海关AEO高级认证企业#xff0c;注册资金1亿元#xff0c;是中国领先的大数据科技公司——神州控股的全资子公司。科捷物流融合B2B和B2C的客户需求#…业务背景
北京科捷物流有限公司于2003年在北京正式成立是ISO质量管理体系认证企业、国家AAAAA级物流企业、海关AEO高级认证企业注册资金1亿元是中国领先的大数据科技公司——神州控股的全资子公司。科捷物流融合B2B和B2C的客户需求基于遍布全国的物流网络与自主知识产权的物流管理系统为客户提供定制化的一站式供应链服务在全国拥有231个仓储中心总面积超100万平方米年运送货值超5000亿元日发送包裹超40万个并在IT、通讯、精密仪器、汽车配件及电商物流领域处于行业领先地位。 神州金库平台经过十几年的更新迭代支撑了科捷物流自营仓储体系、众多电商平台商家、第三方物流公司的核心业务积累了庞大的数据量。为应对持续增长的业务规模以及每年多次的电商大促活动急需寻找更加高效高性能的数据存储方案。
现状与挑战
神州金库服务端采用微服务架构体系设计不同的业务模块采用独立的集群部署模式技术栈基于Java Spring框架构建数据库目前主要使用 MySQL 主从集群多台高性能物理机部署通过 MyCat 做代理层进行读写请求转发。前端接入了多种不同的客户端形态包括Web、APP、IoT设备、扫描枪、计重器、机器人、报表、第三方API等等。 随着数据量的持续快速增长MySQL 的存储容量即将达到上限SQL 响应时间开始变慢业务受到影响。如果维持现有的技术架构下一步势必要引入分表机制同时扩展容量更大的集群这其中数据迁移就是非常大的工程量应用端还要引入额外的 sharding 中间件进行改造后续数据库维护成本和难度成倍上升。
其次大量的数据报表和分析需求凸显仅仅依靠 MySQL 从库提供分析查询能力效率已经达不到业务需求。某些场景下汇总数据的时效性要求非常高直接影响到下一步的业务决策引入传统的T1离线分析方案无法满足。
除此之外在应对电商大促场景下需要数据库提供足够的并发能力响应比平时多出几十倍的流量高峰同时数据库还可以保证稳定的性能。在平时业务量较小的时候需要缩减配置控制成本达到弹性易于扩展的目的。
基于以上需求技术团队决定引入分布式数据库代替 MySQL 单机数据库在充分考虑了应用和数据双方面迁移难度以及一系列 POC 验证后选择了使 TiDB 来替换 MySQL并用神州金库的核心子系统 WMS 作为首期试点项目。
选择使用 TiDB 的主要因素有 1、语法层面高度兼容 MySQL应用端代码中没有使用 TiDB 不支持的特性 最小程度减少应用改造成本更换数据库连接串即可。 2、存储计算分离架构能够满足弹性扩展需求针对不同时期的业务量动态调整节点达到所需的性能和容量还可以把不同业务单元的 MySQL 库合并到一个 TiDB 集群中自带高可用特性省去了 MySQL 从库的硬件成本数据库维护起来简单高效。 3、一站式 HTAP 体验同时满足交易型和分析性业务场景且对应用端透明。 4、开源产品技术社区活跃产品迭代快碰到问题容易解决。
TiDB 解决方案
测试
为赶在双11之前完成迁移任务我们做前期做了充足的测试工作包括应用兼容性测试和改造、多轮带实际业务的压力测试、模拟未来数十倍数据量的性能测试、稳定性测试、高可用测试、生产迁移演练等。在压测中选取了仓储业务中最核心的出库流程一共包含6个场景分别是创建出库单、调度、创建波次、单据复核、单据交接、交接确认。 其中稳定性测试过程中除了使用传统的长时间高压业务负载还引入了 Chaos Mesh 混沌测试对CPU、内存、网络等发生异常情况进行模拟观察 TiDB 在测试期间的表现。从监控显示压测期间资源使用率和数据库响应时间都非常稳定。 迁移
生产环境 TiDB 集群部署架构和数据迁移流程如下图所示 在 TiDB 集群部署完成后使用官方提供的数据迁移工具 TiDB Data MigrationDM开始把全量和增量数据同步到 TiDB 中然后找一个业务低峰期切断应用端到 MySQL 的流量待 DM 把数据追平后使用校验工具 Sync-Diff 对上下游数据做一致性检查校验完成开启 TiDB 到 MySQL 的回退链路防止切换出现故障可以随时回滚到 MySQL。验证 TiDB Binlog 同步正常以后把应用端数据库连接切换到 TiDB 代理层的VIP通过 HAProxy 转发请求到 TiDB 计算层。
收益
迁移之后经过一个月的观察和调整各方面的性能指标都很稳定P99 延时基本在100ms以下服务器资源使用率普遍较低各节点压力均衡。10月31日晚上9点左右迎来了双11的第一轮业务高峰期一直持续到11月3日在这期间 P99 延时没有明显波动但是集群 QPS 较平时上涨了5-8倍最高峰值达到1万多。 在11月1日和11月11日两轮业务高峰期TiDB 均表现得非常稳定没有发生任何故障和性能问题。本次迁移的 WMS 3.0在双11期间的流量约占整个金库系统的10%基于目前 TiDB 的优秀表现我们有充足的信心把所有业务系统逐步迁移到 TiDB。
短期来看TiDB 可能需要投入较高的硬件成本但是随着数据规模增长TiDB 的性价比会大幅提升。首先 TiDB 的数据压缩比非常高三副本所需要的存储空间远低于三台 MySQL 主从节点这意味着三台 TiKV 可以存储比 MySQL更多的数据。其次要提高数据库整体并发能力只需要增加 TiDB Server 节点 要扩展数据库容量只需要增加 TiKV 节点从运维成本和硬件成本都要低于 MySQL。
问题
从单机数据库到分布式数据库除了语法层面的兼容性之外我们还需要关注相同的 SQL 表现行为是否一致。
例如在早期的测试中发现当不显式指定排序字段时MySQL 查询结果能得到固定的顺序但是在 TiDB 中就会出现结果集顺序不稳定的情况这主要是分布式特性带来的表现差异。TiDB 会把扫描数据的请求并行下发给多个 TiKV 节点如果没有强制使用排序字段受 TiKV 返回数据时间不一致的影响最终的汇总结果必然没办法保证顺序这就要求业务开发过程中要保持良好的 SQL 编写规范。
再就是使用 TiDB 普遍会遇到的热点问题上线初期由于某张表的索引建立不当导致某个索引读热点问题非常严重高峰期能达到100多G/min的流量。 我们从三个方向进行了优化首先找到热点所在的 Region 尝试做切分会有短暂的效果但是受 Region 调度影响读热点依旧存在。然后尝试了自动化 Load Base Split发现效果也不好。最后回归 SQL 本身仔细分析了业务查询逻辑和索引使用情况重新调整索引后有了明显效果但由于这是一个业务上小于当前时间的范围查询某些 Region 的负载还是会高一些 再配合定期扫描 Region 流量超出阈值做切分的脚本热点问题得到完美解决。 此外还碰到了 TiDB 产品本身的bug我们生产环境使用了v5.3.2版本在该版本下当 limit offset 值特别大的时候如果此时碰上 IndexHashJoin 会导致 Session 处于假死状态并且持续占用 TiDB 节点内存无法释放同时也无法kill。早期因为这个问题出现过几次 TiDB 节点 OOM 的情况只能不定期重启 TiDB Server 解决。经过仔细分析排查后定位到这是产品bug可以通过 HashJoin 关联方式绕过最后用 SQL Binding 的形式临时处理掉了。不过业务上这样的 SQL 比较多目前依然存在这个问题计划通过版本升级的方式v5.4.3彻底解决。
未来展望
整体来说此次 WMS 3.0系统迁移非常顺利各方面都能够满足预期我们也期待未来把更多的业务系统接入到 TiDB 中在更多场景中感受分布式数据库带来的魅力助力业务的高速增长。
