通过优锐课核心java学习笔记中，我们可以看到，码了很多专业的相关知识， 分享给大家参考学习。
之前，我们讨论了MySQL分片的应用程序和设计挑战以及可能导致并影响你的业务灵活性的一些相应业务挑战。 但是，MySQL如何应对DevOps挑战呢？
作为参考，以下是有关MySQL分片的简要说明：MySQL分片是将MySQL应用程序工作负载划分到多个不同的MySQL数据库服务器上的策略，从而允许查询和数据CRUD操作散开。 它围绕MySQL的单一写主体系结构工作，尽管具有权衡取舍，但仍具有扩展写和读的能力。 这是一个很大的DevOps项目。
而且，由于我们已经了解了MySQL分片对业务规则支持的挑战，因此我们来看看“屋后”：MySQL分片的DevOps挑战。
1.数据维护
一旦选择了分片密钥，就需要在MySQL服务器阵列中物理分布数据。 这些服务器中的每一个都将需要其自己的数据库才能拥有自己的一组数据分区。 初始数据分发可以是手动的； 那更多的是“一次性设置”。但是，随着工作量的增长会发生什么？ 理想情况下，每个碎片都平均增长，但有时生活会发生...
碎片增长和热点
MySQL分片阵列存在两个主要的正在进行的数据维护能力挑战：
- 碎片增长
- 碎片热点
分片增长意味着你的一个或多个分片已准备好超过基础服务器的存储容量。热点意味着你的一台或多台分片服务器即使没有达到存储容量，也正在争用CPU或网络流量。分片增长和热点都会导致服务器性能下降，并且都具有类似的解决方案：拆分本地分片，然后将数据（例如一半）移至其他MySQL服务器。这为DevOps带来了巨大的工作。
从业务角度来看，碎片增长是积极的；增长是好的。但是，这种增长代表着一些DevOps挑战，因为这意味着进一步的数据分发是必要的。简而言之，每个MySQL服务器都需要足够的“备用空间”来增长，否则事务将开始变慢，甚至不会失败。最佳做法是至少有40％的可用存储空间，平均CPU利用率在60％到70％之间。一旦存储量超过90％，将对MySQL性能产生影响。服务器要么需要对其磁盘和/或SAN进行升级，要么需要拆分本地分片，将新的“半”分片移至其他MySQL服务器。理想情况下，将分片移动到新服务器以最大程度地增加增长潜力，但有时CAPEX预算要求合并。在“加倍”分片的情况下，确保新的拆分分片不会在其新的共享服务器上创建竞争非常重要，否则你将不得不再次移动它。这很容易造成一些重大的MySQL分片DevOps挑战。
分片热点意味着访问/数据偏斜。充其量只是暂时的，并且随着时间的流逝会自行解决。最糟糕的是，这意味着MySQL分片密钥（策略）有问题，可能需要重新研究。这将需要重新分片整个数据工作量，这意味着大量的停机时间或大量的冗余硬件支出。分片增长耗尽了本地存储，而分片热点会引起网络，CPU和/或潜在的存储争用。热点不是存储容量的问题；可能还有很多磁盘空间。但是，数据库使用模式取决于本地服务器上驻留的数据，因此处理此类热点的最直接方法是进一步分区本地分片，这意味着MySQL分片会带来更多的DevOps挑战
管理分片拆分可能很棘手。对于DevOps，最简单的解决方案是使碎片脱机，拆分，将新的一半碎片移至新服务器，更新shard：server映射LUT，然后将脱机的碎片重新联机。这将导致应用程序（正常）由于脱机分片上的所有事务而失败。从业务角度来看，这意味着使部分客户，功能部件或功能脱机。例如，某些大型游戏公司具有定期维护，并且正在修改的分片上的所有客户（数千）都离线了几个小时。
但是对于需要高可用性的高容量/高价值MySQL应用程序，由于每个分片都是冗余的（例如，每个分片都有用于HA的从属），因此可以在该从属上进行分片更改，而不会影响生产。 分割并移动分片后，就需要复制以使从站追随主站的位置。 当准备就绪时，提升从属，降级为主并进行转换。 这样可以以最少的停机时间来换取更多的DevOps努力。
一旦分片被分割，并且一半的工作负载与新的分片一起移动到另一个（理想情况下是新的）节点，现在包含一半数据的原始本地服务器的工作负载将减少50％。如果不是，则可能需要重复分片过程。如果例如由于预算限制而将新创建的分片改为移动（共享）另一台就地服务器，则这尤其可能。在这种情况下，需要仔细检查该服务器的新使用模式，否则可能会发生“抢劫Peter付钱给Paul”的情况。
分片合并可能会定期有用。如果业务变化，会发生什么？或者用户访问模式出现高峰/季节性变化，例如，黑色星期五，黄金时段或单身一天？在一个季节性高峰期，可处理3到5倍以上访问者的MySQL分片阵列在今年余下时间严重超出了容量。但事实证明，由于分片合并所需的工作量与分片拆分所需的工作量相似，因此许多企业级MySQL分片部署都无需担心。在这种情况下，所有后续的分片拆分都将移至共享当前使用的MySQL服务器，而不是部署新的。
2. 基础设施维护
“数据维护”的另一面是基础架构。 无论是碎片增长，热点，分裂还是shard：server映射，上述每一项都需要DevOps来部署，升级，维护，备份和淘汰/替换服务器。 这些任务中的某些任务可以在云上简化，尤其是部署速度，但仍然需要管理，并且仍然对分片的MySQL应用程序构成挑战，并给MySQL分片的DevOps挑战带来很多挑战。
具体来说，分片MySQL应用程序面临三个主要的基础架构挑战：
- 服务器物流。
- 服务器备份。
- 高可用性（HA）。
MySQL分片阵列的服务器物流分为三大类：MySQL服务器本身（对于HA可能是冗余的），shard：server映射以及整个阵列所需的任何复制策略，例如，以避免跨节点事务。 MySQL服务器非常简单。 以最佳性价比购买（或租用）实例大小。 但是，随着分片阵列的增大，节点开始处于生命的各个阶段。 某种类型的定期背景心跳和/或冒烟测试对于确定哪些服务器性能下降以及将被替换的服务器很有用。 由于HA，所有这些都翻了一番。 在MySQL中，HA通常是通过一个从属实例完成的，该实例是主实例/主实例的完整副本。 因此，这是需要购买/租用（CAPEX）和进行管理（OPEX）的MySQL服务器数量的两倍。 总之，DevOps需要做更多的工作。
碎片：服务器映射对于MySQL碎片数组至关重要。应用程序必须始终知道每个事务哪个MySQL服务器包含数据。通常，这种映射是通过Redis或Memcache完成的，即快速的内存中键/值存储，它们在PK，分片键，数据库名称，服务器ID，服务器IP等之间提供LUT（查找表）交集。允许应用程序进行动态查找，而对运行中交易的影响最小。这还需要部署和维护其他LUT /映射服务器。它们确实应该是多余的；没有这些数据，分片的数组就会瘫痪。
跨节点复制对于本地分片上所需的任何数据都是必需的。这允许本地分片上的事务避免跨节点事务，并且需要对应用程序进行重大修改以提供参照完整性和ACID保证。如果需要跨节点复制，这将为DevOps增加全新的复杂性，确保在每个节点上创建从属进程，在必需的主服务器上设置binlog，并且监视/确保复制滞后在合理范围之内。
备份MySQL分片阵列的挑战
由于阵列中没有一个RDBMS负责所有MySQL服务器，因此没有编程的方法来获得一致的备份。可以使用MVCC启动备份，以确保每台服务器的事务状态一致，但是即使使用NTP（甚至本地原子时钟），本地服务器时间也不会与其他服务器完全匹配。如果每个服务器都完全独立运行，则问题不大。如果业务规则严格避免跨节点交易，那么“足够接近”就足够了。但是，在与许多公司的许多DevOps负责人交谈之后，他们都对备份策略感到不满意。选项包括使用块存储卷，并在单个时间点同时进行块复制。一些云提供商在其托管产品中也具有快照备份选项，但是跨阵列中每个节点的同步快照仍需要同步。同样，从备份中恢复节点可能很棘手，需要使用复制来前滚以匹配其他节点的事务状态。最后，有时再次同步所有MySQL分片可能需要跨分片滚动重启。谈论MySQL分片DevOps的挑战！
所有这些复杂性导致某些部署更加关注HA，而不是确保一致的备份。
3. 高可用性（HA）
最后，让我们讨论与高可用性（HA）相关的MySQL分片挑战。通常，需要分片提供规模程度的MySQL应用程序会提供需要高可用性的高容量/高价值交易。
这意味着DevOps需要确保每个MySQL服务器都是完全冗余的，即每个“碎片”实际上将至少由两台服务器组成，无论是主/从配置还是主/主配置。主/从是最容易设置的，但不能保证事务的一致性。主机/主机，特别是基于证书复制的主机/主机，可确保辅助主机在主主机COMMIT之前拥有交易信息的副本。这样可以保证，如果主服务器在COMMIT之后但在辅助服务器COMMIT之前发生中断，则辅助服务器仍可以完成该事务并兑现主服务器发送回应用程序的ACK。不出所料，与常规的主/从异步复制相比，这种级别的事务一致的HA涉及的设置更多。用高昂的HA交易OPEX。简而言之，创建了许多其他的MySQL分片DevOps挑战。
为什么自动快照不足以实现HA
AWS RDS每隔五分钟自动提供一次快照备份。乍一看，这似乎比为HA部署冗余服务器要简单得多，更不用说设置和维护所需的所有复制（例如，与RDS中已经提供的只读副本不同的不同RDS主服务器之间）。
但是，五分钟的延迟意味着五分钟的事务丢失。这与丢失“进行中”交易不同；如果服务器出现故障，MySQL会（如果不是很常见）丢失“正在进行中”的交易。由于这些交易未完成，因此不会向数据更新发送COMMIT，也不会向应用程序发送ACK。但是，例如，如果交易完成了，就接了订单，并且客户收到了订单确认号，那么客户有合理的期望，如果随后发生服务器故障，交易将继续进行。如果客户的付款方式有所减少，则他们可以根据法律管辖权寻求法律追索权。但是，如果没有HA，即使信用卡公司这样做，该电子商务提供商也将没有该交易的记录。
这是一种笨拙的做法，它会造成不良的新闻报道，受污的品牌烙印等，并退回到DevOps及其MySQL分片上。
还有一个难题，如果你没有在云部署中租用预留实例，这意味着五分钟的备份延迟将大大延长，同时新实例将联机。
摘要
尽管分片MySQL当然是解决MySQL应用程序可伸缩性需求的一种公认策略，但必须睁大眼睛来对待。 需要创建和审查体系结构和物流计划，以帮助避免可能对OPEX和CAPEX预算造成的MySQL分片DevOps挑战。 分片MySQL总是很困难，它的折衷方案可能很多，尤其是在你的DevOps团队维护分片阵列继续进行时的连锁反应。 提前做出决定是很容易的，DevOps最终将为此付出努力和资源，而MySQL应用程序可能因此失去信誉。
> 喜欢这篇文章的可以点个赞，欢迎大家留言评论，记得关注我，每天持续更新技术干货、职场趣事、海量面试资料等等
> 如果你对java技术很感兴趣也可以＋ qq群：907135806 交流学习，共同学习进步。
> 不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代
文章写道这里，欢迎完善交流。最后奉上近期整理出来的一套完整的java架构思维导图，分享给大家对照知识点参考学习。有更多JVM、Mysql、Tomcat、Spring Boot、Spring Cloud、Zookeeper、Kafka、RabbitMQ、RockerMQ、Redis、ELK、Git等Java干货加vx:ddmsiqi 领取啦
