视频
五件你不知道可以用 Redis 做到的事
了解更多信息
速度的未来即将来到您所在城市的一场活动。
加入 Redis Released
分享
Redis Enterprise 的主动-主动地理分布和 Google Cloud Spanner 的复制协同工作，为地理分布式应用程序提供统一的实时数据层。以下是它们的连接方式以及这项技术带来的优点。
设计和开发一个地理分布式应用程序可能很复杂。跨越多个地理位置的应用程序有许多需求，有时这些需求会互相妨碍。地理分布式应用程序需要高可用性、弹性、合规性和跨远程距离的性能。
确保这些跨多云区域的数据库系统中的数据一致性应该是底层数据库技术中的一项关键功能。而且这不应该是开发人员关注的问题。
在这篇博客文章中，我们讨论了 Redis Enterprise 的Active-Active 地理分布和Google Cloud Spanner 复制的结合，这两者共同为地理分布式实时应用程序提供了一个弹性、全球一致的数据层。
Cloud Spanner 是一个完全托管的数据库服务。它是 Google Cloud 向大众提供基于 ACID 的一致性、SQL 关系数据库功能和地理位置之间的同步复制的努力的一部分。Cloud Spanner 支持关键任务应用程序，并且通过在全球范围内提供事务一致性、模式、SQL（ANSI 2011 及其扩展）和针对五九可用性服务等级协议高可用性的自动同步复制，来遵循关系数据库服务。
一个数据层通常由多种数据库技术组成。它们可能包括充当前端缓存以提高速度和性能的内存中数据库，以及传统的NoSQL 数据库或关系数据库，以便将数据持久化到后端记录系统中。
Redis 开源功能强大，但其在多区域部署等各种企业级功能方面存在不足，尤其是在将其用于多区域 Cloud Spanner 拓扑结构的前端缓存时。
如下原理图所示，在两个不同的地理区域（us-east1 和 us-west1）中部署的应用程序在同时进行缓存读写操作时可能会表现得异常。
设想一下，这种应用程序架构是为了支持一个全球分布的实时活动订票系统。过时的信息可能会造成业务损失和糟糕的客户体验。
这不是一个假设示例。不久前，一家票务服务提供商在其系统基于过时信息采取行动时经历了一次重大挫折。因此，来自不同地区的音乐会观众会收到人为的票价，这是由于可用票数不一致而导致无法计算出正确的动态票价。
怎么会这样？以下是流程。
比如，阿丽亚娜·格兰德的一场热门演唱会就要来了。美国西部和美国东部的数据库都列出了库存中的正确票数。到目前为止，一切都很顺利。
但随后出现高速缓存不匹配。西海岸有人购买了 20 张门票，但东海岸数据库并未收到更新。西海岸数据库称有 80 张可供出售的门票，但东海岸仍然称有 100 张。
如果没有人购买门票，这并不太重要。但这是 Ariana Grande 的演唱会，所以你知道演唱会的门票将很快售罄。
在我们的高速缓存附加示例中，x 的值在 us-east1 区域的 Redis OSS 实例中有可供出售的过时门票数量值（仍然是 100 个座位）。现在，当东海岸有人尝试购买这些座位时，就会在 us-east1 区域对 x（可供出售的门票）执行下一个读取操作时出现问题。这是因为 x 仍然有旧的且过时的值，即使这两个区域的 Cloud Spanner 实例有正确的值。
只要我们的解决方案到位，就不会发生这种情况。我们两个会保持同步。没有人需要哭泣——或者在演唱会上为这些座位而醉酒争斗。
借助对主动-主动地理复制的原生支持，Redis Enterprise 可以解决这个问题。通过使用此功能，Redis Enterprise 可以充当跨区域分布式高速缓存，以确保跨区域的数据一致性。这保证了缓存层和记录系统中都具有更强的持久性。
更好的是：无需进行额外的开发工作即可使用 Redis Enterprise 的原生主动-主动地理副本。每个 Redis Enterprise 集群都支持读取和写操作，延迟不到 1 毫秒，且与每个云区域中的底层 Could Spanner 实例和谐合作。无需您做任何特别的事情，数据就会在 Redis Enterprise 集群之间自动复制。将频繁的数据读取访问卸载到 Redis Enterprise 以提高应用程序的响应时间以及优化总体数据访问成本。
更重要的是，Google Cloud Marketplace 中 Redis Enterprise 的主动-主动功能支持五重 9 SLA，就像 Cloud Spanner 在多区域部署中一样。最终结果？性能价格更佳，且无需维护停机时间。
主动-主动地理分布通过在 Redis Enterprise 中使用跨越多个集群和无冲突复制数据库 (CRDB) 的全局数据库，来实现无冲突复制数据类型 (CRDT)。
您可以在不同行业间使用这种部署拓扑来解决众所周知的问题。例如：
自 2017 年推出以来，零售、金融服务和博彩行业中的客户都已使用 Cloud Spanner 支持需要强大一致性和无限可扩展性的应用程序。诚然，这是所有内容。
其中一个示例是零售业，电子商务自必胜客在 1994 年建立第一个在线订购网站以来一直不断进行改造。新冠肺炎 (COVID-19) 疫情迫使零售商重新考虑如何触达并服务客户，例如快速实施路边送货系统。尽管在线购物有所增加，但购物者期待获得实时响应。
那些商业活动需要建立新零售功能的软件基础。新参与者正在通过支持微服务架构、API 优先、云原生和无头 (MACH) 原则的无头电子商务平台，对电子商务软件栈进行民主化。并且必须在从零售商仓库到支持库存供应链的所有区域内发挥作用。
金融服务行业有其自身挑战，例如不断变化的法规要求、网络安全问题和商业模式调整，每项挑战都会影响技术预算。银行机构、金融科技公司和监管机构之间的互动必须无缝运行。
在此，行业也必须响应不断增加的需求。根据世界银行，新冠肺炎疫情增加了数字支付的使用率。报告称，全世界大约有三分之二的成年人会进行或接收数字支付，而发展中经济体的这一比例从 2014 年的 35% 增长到了 2021 年的 57%。
视频游戏行业健康增长——但它也必须应对市场动态，例如新冠封锁前后消费习惯的变化。同样地，推出超级热门游戏（例如 Splatoon 3）的公司给底层应用程序基础设施平台带来了技术难题。要支持数百万名在线玩家、多人游戏支持和游戏内购买的世界范围内的游戏发布，需要强大的计算能力。
Redis 在这三个行业以及更多行业中普遍使用。企业功能提供构建能够满足用户需求的软件所需的数据模型。无论是用字符串、集合和哈希等本机数据结构充当一个简单缓存来存储应用程序数据，用哈希存储用户个人资料，用有序集合跟踪线上销售活动期间的排名前 10 的支出者，用哈希将微服务架构中的会话 externalize，还是用集合或哈希跟踪用户的购买行为，都是如此。由于手头业务需求激发了 Redis Enterprise 的力量并驱动了其利用方式，因此可能性无穷无尽。
例如，RedisJSON 以及RediSearch可以用来对零售应用程序中的产品目录、购物车和订单详细信息建模。它们还可以对零售银行帐户、交易应用程序中的证券投资组合以及零售银行应用程序的提名人详细信息建模。在游戏中，可以将 JSON 和搜索模块的组合用于存储玩家的游戏目录、玩家个人资料和玩家匹配数据。
一家著名的 Google Cloud 客户使用 Redis Enterprise 来存储用户信息和应用程序关键数据，以及在两个地区部署的 Google Cloud Spanner 作为主存储。通过在多区域拓扑中部署 Spanner 和 Redis Enterprise，它实现了两个目标：用于组织分布式工作负载的全球数据存储和缓存引擎，以及具有超快故障转移时间、复杂性降低以及最佳恢复点目标 (RPO) 和恢复时间目标 (RTO) 保证的灾难恢复问题。
扩展和缩减过程也很平滑。通过添加新节点，可以将容量从每秒 100,000 个请求扩展到每秒 100 万个请求，即使是在黑色星期五等需求高峰期间也是如此。您只需支付所使用的容量即可。
我们有关于Redis Enterprise 的主动-主动地理分布和Google Cloud Spanner的丰富信息。要了解您当前缓存策略的状态，请进行五分钟评估，以接收实用的建议。
