扩展系统及其数据库以进行 10k 请求处理。什么是正确的分片或微服务去分布式数据库

Question

"随着数据量的突飞猛进，MySQL无法将写入请求扩展到一个节点之外成为一个杀手级问题。MySQL 的整体架构本质上强制应用程序级分片。当此类实例的数量从 1 个增加到 100 个，然后爆炸式增长到 1000 个时，开发和操作复杂性呈指数级增长。

因此，如果我使用分片来扩展应用程序，那么

1. 我不能将数据库本身用于任何跨分片连接和事务。这似乎是真的，但它是真的吗？

什么是

2. 更好和有效的方法来扩展应用程序以及数据库，例如 10k 并发请求等。 ？？ 我认为使用微服务不是这里的解决方案，还是吗？

Answer 1

1. 答案比简单的真假更微妙。水平 像Vitess(vitess.io(这样的MySQL分片解决方案确实允许你 同时进行跨分片连接和事务，但只是因为 罐头并不意味着你应该。分片架构将执行 最好是设计得好并发挥它的优势，例如偏爱 任何单个事务中的单分片目标写入。 在 Vitess 中启用两阶段提交以支持跨分片写入是可能的，但会付出巨大的性能代价。这种权衡是否值得因应用程序而异，一般来说，调整架构/工作负载被认为是更好的方法。

最好将

2. 微服务视为设计原则，而不是 缩放技巧。此体系结构更适合改进 通过分解整体式部署实现部署的弹性和灵活性 部署到更松散耦合的隔离元素中。因为 管理资源以实现水平分片对齐的复杂性 密切应对在微服务中管理资源的挑战 建筑，Vitess实际上非常适合容器 编排环境，通常在 使用 Vitess Operator for Kubernetes 的容器。

简而言之，水平扩展MySQL既可行又普遍，无论是在微服务架构中，还是在更传统的环境中。

顺便说一句，10K 并发请求是相对模糊的度量。配置良好的单服务器 MySQL 安装每秒处理数十万个查询并不异常，因此请记住，您可能面临的任何扩展挑战也可以通过优化代码、查询、架构和/或 MySQL 配置来解决。