尽管这段时间因为疫情的原因，部分原先的工作有所延迟，但总体来说，大方向的事情基本已经成为板上钉钉的事情了。如果让我选择今年要做的几件事情，我认为有三个清晰的方向需要关注，也就是说，不仅是从技术层面，而是从综合的业务使用场景和整体演进过程。第一个清晰的流是备份和恢复。这些年好像都忘记了。忘记它没关系。一旦你想记住它，基本上就来不及了。云环境确实提供了一些便利性和稳定性，但并不意味着你不需要进行投资来改进和补充。如何更高效的完成备份，使用最具性价比的存储方式，恢复效率稳定可控，应该是我们备份恢复持续迭代改进的主要目标。在任何优先级面前，备份和恢复在业务层的意义可能很单薄，但这是关系到数据生死存亡的大事，请放在最基础、最紧迫的工作上。第二个明流是高可用性。我们有传统概念中理解的高可用，也有基于分布式环境的高可用解决方案。高可用是指我们的后端服务不是死板的、不可移动的，而是在保证业务可用性的前提下，实现业务和系统的可用性。高可用可以做的事情很多，不同阶段的benchmarking目标也大不相同。换句话说，我们可以在不要求数据库层100%可用的情况下，结合业务层，基于几秒的闪断交换业务服务。真正的高可用，其实可以做的事情很多，有有很大的改进空间。第三个清算流程是数据传输。数据传输是一个更大的系统，数据迁移是其中的一个子集。如何让数据流进流出，实现环境间和异构环境间的数据同步，提供多维度、近实时的数据访问，算是盘活了原本分散的数据。数据传输可以打破很多技术壁垒，提供更多更灵活的数据端解决方案。当然也有同学说这三个任务是不是太简单了。我们可以在此基础上做一些延伸和补充说明，使这三股清流更加清晰。对于备份和恢复，毫无疑问首先要提高现有的备份效率和存储。在备份方式上，要做到一次性全量，永远增量的目标。需要充分结合binlog方案，实现有效结合全量+增量+binlog的快速恢复方案。基于binlog的数据闪回方向，可以做深做细，让数据恢复更加灵活，比如提供自助数据采集方面，基于binlog端的备份可以逐渐入驻一个binlog集市，而基于bazaar的方案也可以为后续的数据传输打下坚实的基础。备份和恢复不是死板的，而是可以提供其他维度的功能。例如，我们可以基于快照设计的思想快速恢复某个数据库，然后在其上进行业务压力测试或以真实数据量进行SQL优化服务。高可用，如果实现了同机房和跨机房的高可用方案，那么接下来要做的就是盘活高可用方案的发展空间。比如我们本来以为高可用就是数据库层老老实实不动。在达到高可用目标的前提下，数据库层可以更加主动，比如更流畅的在线升级、秒级业务中断的快速服务切换、秒级服务切换和跨机房高可用方案。对此，我们需要扭转我们固化的高可用认知，选择更加主动灵活的高可用解决方案。数据流转，同类型数据之间的同步，异构数据之间的同步，是我们需要打通的部分。数据的流动性也可以反映业务方相应的成熟度。我们可以在流量采集端实时抽取数据，然后基于binlog服务或者binlogbazaar实时消费数据，在跨环境维护中引入数据生命周期管理，可以实现基于版本的管理模式，基于业务使用模式，实现缓存、持久化存储、文件存储等。维度数据存储方案可以降低数据访问成本，通过数据关联发现更多数据价值。
