转转《转转高效改表平台的演进之路》

如何获得讲师PPT：

扫码关注公众号，后台回复「Q107」即可获得讲师PPT哟～

还能一键订阅后续精彩活动内容～

Q&A环节答疑：

1、优化延迟监控方面，是怎么支持业务动态调整延迟阈值的？ 然后这种调整会不会对改表操作的稳定性和数据一致性产生影响？

首先，关于这个功能本身，它支持一个接口，允许用户去修改某些参数。例如，在开始改表时，我们可以定义阈值，比如设定为60秒。此接口支持更新阈值参数，这是通过ghost功能实现的，而PD暂时不支持此功能。

对于稳定性，通常来说，如果是从较大的值修改为较小的值，对系统的影响应该不大。然而，如果是从小值改到大值，可能会存在风险，因此我们需要谨慎处理。但总体上，这一功能对系统稳定性影响不大。

关于一次性处理的问题，虽然我没有查看具体的源代码，但根据我的理解，如果接口存在问题，那么它就不应该被公开。通过查看处理日志，我发现它是通过控制数据块的大小来进行拷贝的。比如，原先可能是每1万行拷贝一次全量数据，如果调整参数，可能会变成每200行或2000行进行一次拷贝。这种设计旨在降低拷贝数据本身带来的性能影响，因此，对数据一致性不会产生负面影响。

综上所述，这一功能在合理使用的情况下，既提供了灵活性，又保证了系统的稳定性和数据一致性。

2、在改表过程中，你们怎么确保业务的读写操作不被长时间锁定的？或者说，有没有出现过影响业务的情况，然后是怎么解决的，这块可以展开讲讲吗？ 

首先，无论是使用原生方法还是工具进行改表操作，都需要获取原数据锁，这在之前的PPT中已经详细介绍过。如果在改表过程中，业务进行了大规模的查询操作，这可能导致改表任务无法获取到所需的原数据锁，从而使任务被阻塞。一旦改表任务被阻塞，由于无法获取原数据锁，系统可能会尝试扩大锁的范围，甚至将整个表锁定。这样一来，后续的改版任务以及所有相关连接都将无法进行读写操作，对业务产生严重影响。

为解决这一问题，建议在改表过程中避免进行大规模查询操作。如遇到类似情况，可以考虑暂停改表任务。我们之前的测试表明，当遇到原数据锁时，暂停改表任务可以使其停止对表的修改操作，从而释放锁并等待锁的解除。这样，只有确保锁被正确释放后，业务才能恢复正常。

3、智能改表，SQL解析失败的话，系统的容错这块是怎么样的？ 

在智能改表功能刚上线的几个月里，我们确实遭遇了不少解析失败的场景。这些失败有的是因为业务中使用了保留字段，有的是因为代码本身存在逻辑错误。由于改表前我们进行了预处理，即在测试环境中先执行改表方案，只有在测试环境成功通过后，我们才会将方案应用到线上环境。如果测试环境执行失败，我们会认为方案存在问题，并将此情况以工单的形式反馈给业务方，提示他们解析失败。

为了应对这类解析失败的情况，我们增加了重试机制。当业务方选择重试时，我们不再走智能改表流程，而是直接使用工具进行改表，以提高容错能力。

此外，为了确保系统的安全性，我们还设定了安全边界。如果某个需求本不应使用快速改表功能，但我们错误地使用了它，我们设置了一个超时限制来应对这种情况。因为我们认为快速改表应该在秒级别内返回结果。如果执行时间超过十秒，我们会认为这是不合理的，并会终止操作，以减少对系统可能产生的影响。

4、请问老师，使用gh/pt 改表，有没有最佳实践可以分享下，比如操作前准备、操作的监控、操作后的验证？

网上有很多关于最佳实战的文档，你可以查找一下。这两个工具本身非常复杂，具有大量的参数，可能多达上百个，因此现在让我直接写出改表的命令是相当困难的。通常，我们都是基于经验进行操作。例如，在每次改表时，我们会记录所使用的命令和参数，这些参数通常都是固定的几个。因此，要掌握这两个工具，一方面需要查阅相关资料，另一方面需要多进行实践尝试。

在改表前，我们还需要对目标表进行前期评估，确定其能接受的最大影响范围。例如，我们需要考虑延迟和负载等因素，并设置相应的阈值。当延迟或负载超过这些阈值时，改表操作会进行安全控制。然而，目前PD在监控和操作方面还存在一些不足，因此我们主要依赖案例来进行操作。

在改表过程中，数据一致性的校验至关重要。幸运的是，这两个工具提供了接口支持我们进行脚本操作，这有助于我们进行监控。此外，我们还需要关注磁盘空间和锁的监控。改表过程中会产生大量的日志，并且容易触发原数据锁，因此我们需要对这些方面进行密切的监控。

总的来说，掌握这两个工具需要不断的实践和学习。如果你对我们的代码或逻辑感兴趣，可以查看我们在网上分享的内容。如果有任何疑问或想法，我们非常愿意与你进一步沟通。

5、请问怎么有效地避免大查询或大事务导致的表锁定问题？有哪些技术或策略可以推荐？ 

关于负载保护项目，我们旨在避免业务服务中出现过大的查询和异常查询。由于业务团队对业务本身非常熟悉，他们了解正常的查询范围和标准。因此，我们构建了一个系统来实施控制机制。例如，当查询时间超过100秒时，我们认为这是不合理的，并通过负载服务系统进行处理，可能是丢弃这类查询或发出告警。

此外，我们也考虑了GPS数据的异常情况，并设定了相应的阈值。在具体场景和环境下，我们可以提前预估和预判潜在的负载问题。实施负载保护后，我们取得了可观的收益，特别是在处理跑批任务时。由于新员工可能对业务不够了解，他们可能在不注意流量的情况下触发大量长时间运行的查询。

如果没有负载保护机制，业务团队可能需要花费至少十分钟的时间来感知问题并到数据库处理，这对聊天业务来说可能意味着十分钟的中断。对于核心业务，这样的中断可能触发第四或第三级别的故障。因此，负载保护机制能够及时发现问题并进行处理，这是我们分享的重要经验。

6、改索引在这个系统吗？ 有做什么把控？乱改索引可能出现大问题

关于这个问题，我们目前采取了一项限制措施。由于我们无法直接控制业务对索引的需求，我们遇到了一种情况，即业务经常或偶尔会出现重建索引的操作。有时，如果不加注意，可能会先删除索引再重建，这可能导致不必要的风险。

针对这种场景，我们进行了相应的改进：当尝试删除索引时，若该操作不涉及费用，系统会要求进行二次确认，以确保操作的准确性。

此外，关于唯一索引，由于它本身存在容易丢失数据的风险，我们目前不支持将唯一索引与其他操作一起使用。这也是为了规避潜在的数据丢失风险。

总的来说，我们通过这些措施来增强系统的稳定性和数据安全性。

7、有些做了分库分表的表怎么变更？

我们公司的分工表采取的是灵活的拆分策略，其中包括垂直拆分和水平拆分。水平拆分主要是将一个大型表，例如包含一亿条数据的表，按照特定的规则拆分成多个小型表，每个表包含大约一千万条数据。这种拆分是逐行进行的，确保拆分后的表结构保持一致，这样更易于理解和操作。

拆分的目的是优化性能和管理效率。对于前期的大表，我们通常会按照二的倍数进行拆分，比如拆分成8个、16个或32个表。在进行这种拆分时，我们内部有一套映射逻辑，只要提交的工单所在的子库在我们的逻辑表中有记录，系统就会自动进行补全操作。例如，如果我们有30个表（或库），临时修改了其中一个，系统会通过映射表自动对其他29个表进行相应的补全，确保数据的一致性和完整性。最终，我们会生成一个包含所有32个工单的完整改表结果。