Myntra如何设计其用户账户的数据库架构？

Myntra用户帐户服务是创建和管理帐户所需的用户属性。帐户服务将存储用户凭据、主要/次要电子邮件/电话、性别、年龄等属性（完整列表可在后续部分中找到）。所有这些属性都在帐户级别，不包含任何其他域/服务的信息。此服务还管理帐户的不同状态，如活动、删除、阻止等。由于多个用户可能共享一个帐户和可以提供用户配置文件级别信息的不同来源，不同的配置文件服务将了解帐户下的不同配置文件。

功能特点：

• 使用用户信息和凭据创建一个新的用户帐户。
• 使用凭据对用户进行身份验证。
• 通过userId返回用户信息。
• 验证用户电子邮件和电话号码。
• 更新用户信息。
• 发送恢复电子邮件和 OTP。
• 将用户状态更新为已阻止、活动和已删除。

数据库

设计系统最关键的方面之一是数据库选择和建模。

1. 高度可靠并拥有管理备份、恢复和迁移的专业知识
2. 多键分组查询能力
3. 需要二级索引

DB选择过程

• 我们没有考虑 Cassandra/Aerospike，因为我们想要强一致性。
• 我们确实考虑过HBase，但是选择HBase的数据量不是很大，我们的只有几GB，而且HBase不支持二级索引。
• 我们确实考虑过 MongoDB，但我们的访问模式是读写比例是90/10，，因此无法更好地利用 MongoDB，而使用 MySQL，它在行业中得到了充分证明的可靠和一致。
• 我们还考虑使用 Vitess over MySQL 来实现 Sharding，我们发现基于数据调整的结果并不多，而且数据量每年都在增长。在接下来的 10 年中，即使增长到几 TB，单个 MySQL master 也可以承担负载。
• 我们最终发现 MySQL 最适合我们的要求

为什么选择 MySQL

1. 行业证明，20 多年的高可靠性和一致性数据库，在数据管理、HA、DR、BK、迁移方面的大量经验。
2. 当前的写入负载约为每台服务器几千 RPM，使用 MySQL，即使使用单个主服务器，我们也可以轻松地将其扩展 10 倍。
3. 90-10 比例的读/写模式，更适合 MySQL，其中 70% 的 Reads 将被 Redis 覆盖，只有 30% 将转到 MySQL。
4. MySQL8 还提供了 InnoDB 集群，它是组复制以支持 Quorum 类型的读取和写入，在多个主节点上支持强一致性，切换回普通的 MySQL 只是一个配置更改。

数据库集群

使用 MySQL 8，但同时我们正在评估多主集群模型，有两种：组复制和InnoDB 集群。

• 组复制Group Replication

组复制使拓扑最终同步复制（在属于同一组的节点之间）成为现实，而现有的 MySQL 复制功能是异步的（或至多是半同步的）。因此，可以提供更好的高可用性保证，因为交易以相同的顺序交付给所有成员（尽管在每个成员接受后以自己的节奏应用）。

组复制通过分布式状态机实现这一点，并在分配给组的服务器之间进行强协调。这种通信允许服务器在组内自动协调复制。更具体地说，组维护成员身份，以便服务器之间的数据复制在任何时间点始终保持一致。即使服务器从组中删除，添加时也会自动启动一致性。此外，对于离线或无法访问的服务器，还有一种故障检测机制。旁边的图显示了您将如何将 Group Replication 与我们的应用程序一起使用来实现高可用性。

• InnoDB 集群

它旨在使高可用性更易于设置、使用和维护。InnoDB Cluster 通过 MySQL Shell 和 Admin API、Group Replication 和 MySQL Router 与 X AdminAPI 一起工作，将高可用性和读取可扩展性提升到一个新的水平。也就是说，它将 InnoDB 中用于克隆数据的新功能与 Group Replication 以及MySQL Shell和 MySQL Router 相结合，以提供一种设置和管理高可用性的新方法。

1. 集群设置有一个主（想想标准复制用语中的主），它是所有写入（更新）的目标。
2. 多个辅助服务器（从服务器）维护数据的副本，可以从中读取数据，从而在不增加主服务器负担的情况下读取数据，从而实现读取可扩展性（但所有服务器都参与共识和协调）。
3. 组复制的合并意味着集群是容错的，组成员资格是自动管理的。
4. MySQL 路由器缓存 InnoDB 集群的元数据，并执行到 MySQL 服务器实例的高可用性路由，从而更容易编写应用程序与集群交互。

由于这个集群为我们提供了更好的可扩展性和容错性，我们决定使用 InnoDB 集群而不是单主多从设置。

数据库建模亮点

1. 每个租户都有自己的架构，很可能根据需要相似或不同
2. 目前，将有 3 个 DB 模式
3. Master - 包含租户和客户端
4. Myntra — 所有 Myntra 消费者
5. 内部——物流、仓库、卖家和所有内部用户
6. 获取用户详细信息的单用户表
7. 用户凭据 - 一侧散列
8. 社交链接作为单独的表格 - 将来可能会弃用，并且在用户个人资料要求中不需要
9. 图像记录——从 Cassandra 转移到 MySQL 中并按需提供服务
10. 电子邮件、电话和社交档案表
11. URT — 在数据库级别维护多请求事务
12. 恢复请求 - 用于恢复帐户

更多点击标题