这是用户在 2024-7-28 9:39 为 https://redis.io/blog/google-cloud-spanner-for-global-real-time-applications/ 保存的双语快照页面,由 沉浸式翻译 提供双语支持。了解如何保存?

dot The future of fast is coming to an event in your city.
dot 快速的未来即将在您所在城市的活动中到来。

Join us at Redis Released
加入我们,Redis 发布会

Turbocharge Cloud Spanner with Redis Enterprise Active-Active for Global Real-Time Applications
通过 Redis Enterprise Active-Active 为全球实时应用程序加速 Cloud Spanner

Redis Enterprise’s Active-Active Geo-Distribution and Google Cloud Spanner’s replication work together to provide a unified real-time data layer for geo-distributed applications. Here’s how they connect and the benefits the tech provides.
Redis Enterprise 的主动-主动地理分布和 Google Cloud Spanner 的复制协同工作,为地理分布的应用提供统一的实时数据层。以下是它们如何连接以及该技术所带来的好处。
 

Designing and developing a geo-distributed application can be complicated. Applications that span multiple geographic locations have multiple requirements, and sometimes those get in the way of one another. Geo-distributed applications need high availability, resiliency, compliance, and performance across remote distances.  
设计和开发地理分布式应用程序可能很复杂。跨多个地理位置的应用程序有多个要求,有时这些要求会相互干扰。地理分布式应用程序需要在远程距离上具备高可用性、弹性、合规性和性能。

Ensuring data consistency in these database systems across multicloud regions should be a critical feature in the underlying database technologies. And it should not be a developer’s concern. 
确保在这些数据库系统中跨多云区域的数据一致性是底层数据库技术中的一个关键特性。这不应该是开发者的关注点。

In this blog post, we discuss the combination of Redis Enterprise’s Active-Active Geo-Distribution and Google Cloud Spanner’s replication, which together provide a resilient, globally-consistent data layer for geo-distributed real-time applications. 
在这篇博客文章中,我们讨论了 Redis Enterprise 的主动-主动地理分布Google Cloud Spanner 的复制的结合,这两者共同为地理分布的实时应用提供了一个弹性、全球一致的数据层。

two maps of the world

Cloud Spanner is a fully-managed database service. It’s part of Google Cloud’s effort to bring ACID-based consistency, SQL relational database capabilities, and synchronized replication among geographical locations to the masses. Cloud Spanner supports mission-critical applications, and it complies with relational database services by offering transactional consistency at a global scale, schemas, SQL (ANSI 2011 with extensions), and automatic, synchronous replication for five-nines SLA high availability.
Cloud Spanner 是一项完全托管的数据库服务。它是 Google Cloud 努力将基于 ACID 的一致性、SQL 关系数据库功能以及地理位置之间的同步复制带给大众的一部分。Cloud Spanner 支持关键任务应用程序,并通过在全球范围内提供事务一致性、模式、SQL(ANSI 2011 及扩展)和自动同步复制来符合关系数据库服务的要求,以实现五个九的 SLA 高可用性。
 

That syncing feeling  同步的感觉

A data layer generally consists of multiple database technologies. They may include an in-memory database serving as the front-end cache to improve speed and performance, and also a traditional relational database or a NoSQL database to persist data in the backend system of record. 
数据层通常由多种数据库技术组成。它们可能包括一个作为前端缓存的内存数据库,以提高速度和性能,以及一个传统的关系数据库或一个NoSQL 数据库,用于在后端记录系统中持久化数据。

Redis Open Source is powerful, but it falls short on various enterprise-grade features like multi-region deployments, particularly when it’s used in a front-end cache for multi-region Cloud Spanner topology. 
Redis 开源版本功能强大,但在多区域部署等各种企业级功能上有所不足,特别是在作为多区域 Cloud Spanner 拓扑的前端缓存时。

As the following schematic diagram illustrates, an application deployed in two different geographic regions (us-east1 and us-west1) may behave erratically in the event of simultaneous cache reads and writes. 
如以下示意图所示,部署在两个不同地理区域(us-east1 和 us-west1)的应用程序在同时进行缓存读取和写入时可能会表现出不稳定的行为。

google spanner inconsistent data
Redis OSS Cache for Cloud Spanner
Redis OSS 缓存用于 Cloud Spanner

Imagine that this application architecture is meant to support a globally distributed real-time event booking and ticketing system. Outdated information could cause losses in business and poor customer experience. 
想象一下,这个应用架构旨在支持一个全球分布的实时事件预订和票务系统。过时的信息可能会导致业务损失和糟糕的客户体验。

It’s not a hypothetical example. Not long ago, one ticketing service provider experienced a major setback when its system acted on outdated information. As a result, concertgoers from different regions received contrived ticket prices due to an inconsistent number of available tickets for correct dynamic pricing calculations. 
这不是一个假设的例子。就在不久前,一家票务服务提供商在其系统基于过时信息操作时遭遇了重大挫折。因此,来自不同地区的音乐会观众因可用票数不一致而收到了人为设定的票价,导致动态定价计算不准确。

How can that happen? Here’s the process. 
这怎么可能发生?这是过程。

Let’s say a popular concert is coming up for, say, Ariana Grande. Both the U.S.-west and U.S.-east databases have the correct number of tickets listed in the inventory. So far, so good. 
假设有一场流行的音乐会,比如说,阿丽亚娜·格兰德的演唱会。美国西部和美国东部的数据库中都有正确数量的票在库存中。目前为止,一切都很好。

  • At time = t(0), x has a value of the number of available Ariana Grande concert tickets for sale in Cloud Spanner; let’s say that’s 100 remaining tickets. But it’s a popular concert, and tickets sell fast. At time = t(1), the ticketing system has a cache-miss in the us-west1 region; the requested data isn’t found in the cache. Our x is stored on the Redis OSS instance with the value of available tickets for sale. In other words, the ticketing application says there are 100 seats remaining, according to us-west data. 
    在时间 = t(0) 时,x 的值是 Cloud Spanner 中可售的 Ariana Grande 演唱会门票数量;假设剩余 100 张票。但这是场热门演唱会,门票销售迅速。在时间 = t(1) 时,票务系统在 us-west1 区域发生了缓存未命中;请求的数据未在缓存中找到。我们的 x 存储在 Redis OSS 实例中,值为可售门票数量。换句话说,票务应用程序根据 us-west 数据显示剩余 100 个座位。
  • At time = t(2), the ticketing system has a cache-miss in the us-east1 region. Now x is stored on the Redis OSS instance with the value of the correct number of available tickets for sale (still 100 seats). 
    在时间 = t(2) 时,票务系统在 us-east1 区域发生了缓存未命中。现在 x 存储在 Redis OSS 实例中,值为可售票的正确数量(仍然是 100 个座位)。

But then there’s a caching mismatch. Someone on the west coast buys 20 tickets, but the east coast database doesn’t get the update. The west coast database says there are 80 tickets available, but the east coast still says 100. 
但随后出现了缓存不匹配。西海岸的某人购买了 20 张票,但东海岸的数据库没有更新。西海岸的数据库显示还有 80 张票可用,但东海岸仍然显示有 100 张。

That doesn’t matter much if nobody buys the tickets. But this is Ariana Grande, so you know the concert will sell out. 
这没什么大不了的,如果没有人买票。但这是阿丽亚娜·格兰德的演唱会,所以你知道门票会售罄。

  • That is, a write operation on x in the us-west1 region (20 seats sold!) changes the number of available tickets. The Cloud Spanner instances on both regions now have the same and correct value of x with its cross-region replication capability. 
    也就是说,在 us-west1 区域对 x 的写操作(售出 20 个座位!)会改变可用票的数量。两个区域的 Cloud Spanner 实例现在具有相同且正确的 x 值,并具备跨区域复制能力。

In our cache-aside example, the value of x has an outdated value of available tickets for sale (still 100 seats) in the Redis OSS instance in the us-east1 region. Now, a problem arises on the next read operation on x (available tickets for sale) in the us-east1 region when someone on the east coast tries to buy those seats. That’s because x still has the old and outdated value even though the Cloud Spanner instances in both regions have the correct value.  
在我们的缓存旁路示例中,x 的值在 us-east1 区域的 Redis OSS 实例中有一个过时的可售票数(仍然是 100 个座位)。现在,当东海岸的某人尝试购买这些座位时,x(可售票数)在 us-east1 区域的下一次读取操作中出现了问题。这是因为 x 仍然具有旧的过时值,即使两个区域的 Cloud Spanner 实例都有正确的值。

With our solution in place, this just won’t happen. The two of us keep things in sync. Nobody has to cry — or get into a drunken fight at the concert over those seats. 
有了我们的解决方案,这种情况就不会发生。我们两个人保持同步。没有人需要哭泣——也不必因为那些座位在音乐会上醉酒争吵。

The fix? Redis Enterprise 
解决方案?Redis Enterprise

Redis Enterprise can solve this problem thanks to the native support of active-active geo-replication. Using this feature, Redis Enterprise can serve as a cross-region distributed cache to ensure data consistency across regions. That guarantees stronger consistency both in the caching layer and in the system of record.  
Redis Enterprise 可以通过原生支持主动-主动地理复制来解决这个问题。利用此功能,Redis Enterprise 可以作为跨区域分布式缓存,以确保区域之间的数据一致性。这保证了缓存层和记录系统中的更强一致性。

redis enterprise active-active geo-distribution
Distributed Redis Enterprise Cache for Google Cloud Spanner
分布式 Redis 企业缓存用于 Google Cloud Spanner

Better yet: No additional development work is required to use Redis Enterprise’s native Active-Active Geo-Duplication. Each Redis Enterprise cluster supports local read and write operations with under one-millisecond latency, and it works harmoniously with the underlying Cloud Spanner instance in each cloud region. Without you doing anything special, data is automatically replicated among Redis Enterprise clusters. Frequent data-read access is offloaded to Redis Enterprise to improve application response time as well as to optimize overall data access costs. 
更好的是:使用 Redis Enterprise 的原生主动-主动地理复制无需额外的开发工作。每个 Redis Enterprise 集群支持本地读写操作,延迟低于一毫秒,并且与每个云区域中的底层 Cloud Spanner 实例和谐工作。无需您做任何特别的操作,数据会在 Redis Enterprise 集群之间自动复制。频繁的数据读取访问被卸载到 Redis Enterprise,以提高应用程序响应时间并优化整体数据访问成本。

More importantly, Redis Enterprise’s Active-Active feature in Google Cloud Marketplace supports five nines SLAs as Cloud Spanner does in multi-region deployments. End result? Better price performance with no maintenance downtime.  
更重要的是,Redis Enterprise 在 Google Cloud Marketplace 的主动-主动功能支持五个九的服务水平协议,正如 Cloud Spanner 在多区域部署中所做的那样。最终结果?更好的性价比,没有维护停机时间。

active-active replication graph
Distributed Redis Enterprise Cache for Cloud Spanner
分布式 Redis 企业缓存用于 Cloud Spanner

Active-Active Geo-Distribution is achieved by implementing conflict-free replicated data types (CRDTs) in Redis Enterprise using a global database that spans multiple clusters and conflict-free replicated databases (CRDBs).  
通过在 Redis Enterprise 中实现无冲突复制数据类型(CRDTs),使用跨多个集群的全球数据库和无冲突复制数据库(CRDBs),实现了主动-主动地理分布。

You can use this kind of deployment topology across different industries to solve well-known problems. For instance: 
您可以在不同的行业中使用这种部署拓扑来解决众所周知的问题。例如:

  • Disaster recovery  灾难恢复 
  • Distributed session management across geographies 
    跨地域的分布式会话管理
  • Distributed applications spanning multiple geographies 
    跨多个地理区域的分布式应用程序

Who needs this? A short survey of industry trends 
谁需要这个?行业趋势的简短调查

Since its inception in 2017, customers in retail, financial services, and gaming industries have used Cloud Spanner to support applications requiring robust consistency and unlimited scalability. Which, admittedly, is everything. 
自 2017 年成立以来,零售金融服务游戏行业的客户一直在使用 Cloud Spanner 来支持需要强一致性和无限可扩展性的应用程序。可以说,这就是一切。

One such example is the retail industry, where electronic commerce has been reinventing itself since Pizza Hut set up the first online ordering website in 1994. The COVID-19 pandemic forced retailers to rethink how retailers could reach and serve customers, such as quickly implementing curbside delivery systems. And despite the increase in online purchases, shoppers expect real-time responses. 
一个这样的例子是 零售行业,自从 必胜客在 1994 年建立了第一个在线订购网站 以来,电子商务一直在自我重塑。COVID-19 大流行迫使零售商重新思考如何接触和服务客户,例如 快速实施路边交付系统。尽管在线购买增加,购物者仍然期待实时响应。

Those business endeavors require a software foundation on which to build new retail features. New players are democratizing the e-commerce software stack with headless e-commerce platforms that support microservices architecture, API-first, cloud-native, and headless (MACH) principles. And it has to work across all geographic regions, from retailer warehouses to the supply chains that support their inventory. 
这些商业努力需要一个软件基础,以便构建新的零售功能。新参与者正在通过支持微服务架构、API 优先、云原生和无头(MACH)原则的无头电子商务平台来实现电子商务软件栈的民主化。而且它必须在所有地理区域内有效,从零售商仓库到支持其库存的供应链。

The financial services industry has its own challenges, such as ever-changing regulatory requirements, cybersecurity woes, and business model adjustments – each of which affects technology budgets. Interactions between bank institutions, fintech, and regulatory bodies must run flawlessly.  
金融服务行业面临着自身的挑战,例如不断变化的监管要求、网络安全问题和商业模式调整——这些都影响着技术预算。银行机构、金融科技和监管机构之间的互动必须无缝进行。

Here, too, the industry must respond to increased demands. The pandemic increased digital payments usage, according to The World Bank. About two-thirds of adults worldwide now make or receive digital payments, with the share in developing economies growing from 35% in 2014 to 57% in 2021, according to the report. 
在这里,行业也必须应对日益增长的需求。根据世界银行的报告,疫情增加了数字支付的使用。全球约三分之二的成年人现在进行或接收数字支付,发展中经济体的比例从 2014 年的 35%增长到 2021 年的 57%。

The video gaming industry is healthy and growing – but it, too, has to deal with market shifts, such as changes in spending habits pre- and post-COVID lockdowns. Again, the companies that bring out super-popular games (such as Splatoon 3) present technical challenges to the underlying application infrastructure platform. It takes a lot of computational power to support a worldwide game launch with millions of online players, multiplayer support, and in-game purchases. 
视频游戏产业健康且正在增长——但它也必须应对市场变化,例如疫情封锁前后消费习惯的变化。再次强调,推出超级受欢迎游戏的公司(如 Splatoon 3)对基础应用基础设施平台提出了技术挑战。支持全球游戏发布、数百万在线玩家、多玩家支持和游戏内购买需要大量计算能力。

Redis is used extensively in these three industries, among so many more. The enterprise capabilities provide the data models required to build software that stands up to user demand. That’s true whether it’s to leverage native data structures like string, set, and hash as a simple cache for storing application data, hash for storing user profiles, sorted-set for tracking top 10 spenders during an online sale event, hash for externalizing the sessions in a microservices architecture, set or hash for tracking the buying behavior of a user. The possibilities are endless as the business requirement at hand stimulates the power of Redis Enterprise and drives its consumption. 
Redis 在这三个行业中被广泛使用,还有许多其他行业。企业能力提供了构建能够满足用户需求的软件所需的数据模型。这无论是利用字符串、集合和哈希等原生数据结构作为存储应用数据的简单缓存,还是使用哈希存储用户档案,或使用有序集合跟踪在线销售活动中的前 10 名消费用户,或在微服务架构中外部化会话,或使用集合或哈希跟踪用户的购买行为,都是如此。随着业务需求的推动,Redis Enterprise 的强大功能和使用场景是无穷无尽的。

For instance, RedisJSON, along with RediSearch, can be used to model product catalogs, shopping carts, and order details in a retail application. They can also model retail bank accounts, securities portfolios in trading applications, and nominee details for a retail banking application. In a game, the same combination of JSON and search modules can be used to store players’ game inventory, player profiles, and player matchmaking data.  
例如,RedisJSONRediSearch 可以用于在零售应用程序中建模产品目录、购物车和订单详情。它们还可以在交易应用程序中建模零售银行账户、证券投资组合,以及在零售银行应用程序中建模被提名人详情。在游戏中,JSON 和搜索模块的相同组合可以用于存储玩家的游戏库存、玩家档案和玩家匹配数据。

One well-known Google Cloud customer is using Redis Enterprise to store user information and application critical data along with Google Cloud Spanner as primary storage deployed in two regions. By deploying Spanner and Redis Enterprise in multi-region topology, they are achieving two objectives: Global datastore and caching engine for the organization’s distributed workload, and disaster recovery concerns with ultra-fast failover time, reduced complexity, and best Recovery Point Objective (RPO) and Recovery Time Objective (RTO) guarantees. 
一个知名的谷歌云客户正在使用 Redis Enterprise 存储用户信息和应用程序关键数据,同时在两个区域部署 Google Cloud Spanner 作为主要存储。通过在多区域拓扑中部署 Spanner 和 Redis Enterprise,他们实现了两个目标:为组织的分布式工作负载提供全球数据存储和缓存引擎,以及在超快故障转移时间、降低复杂性和最佳恢复点目标(RPO)和恢复时间目标(RTO)保证下解决灾难恢复问题。

The scale-out and the scale-in process is also seamless. By adding new nodes, it is possible to scale from 100,000 requests per second to 1 million requests per second, even during high-demand days such as Black Friday. You just pay for the capacity you use. 
扩展和收缩过程也是无缝的。通过添加新节点,可以将请求量从每秒 100,000 个扩展到每秒 1,000,000 个,即使在黑色星期五等高需求日也是如此。您只需为所使用的容量付费。

Want to learn more?   想了解更多吗?

We have extensive information about Redis Enterprise’s Active-Active Geo-Distribution and Google Cloud Spanner. To learn about the state of your current cache strategy, take a five-minute assessment to receive practical recommendations.
我们有关于 Redis Enterprise 的主动-主动地理分布Google Cloud Spanner 的丰富信息。要了解您当前缓存策略的状态,请进行 五分钟评估 以获得实用建议。