首先,自我介绍一下:建立于 2011 年,Silkke致力于创建可用于各种应用程序,虚拟世界和兼容互联网网站的无与伦比品质的 3D 动态头像。我们的使命是在数字平台上创造一个虚拟形象,与各种品牌整合,通过提供个性化独特体验使品牌更贴近消费者。
创建头像需要多项任务,从对个体的初始扫描到 3D 逼真的克隆。扫描过程涉及四个独立的步骤,即使这看上去并不多,也给一个执行扫描的展台的总体容量带来了很大压力。每个展台每分钟都可以扫描一个人!现在,把这个数字乘以世界范围内的展台数量。
这是一个巨大的工作量。
在此过程中,扩展能力非常重要,因为我们不知道要处理多少个头像。因此,我们使用 RabbitMQ 创建队列,将工作分配给呈现头像一部分的每个处理程序。这样做可以允许我们随着队列容量的增加来扩展处理能力。
这带来了另一个挑战:如何最佳地组织队列中的内容?
随着队列内容的增加,我们无法知道队列中一组指令的顺序。此外,如果我们需要修改即时指令,我们无法编辑某些内容,而无需移除所有初始元素,然后重新对这些元素进行排队,从而改变全局顺序,并有可能导致生产减缓。
首先,我们需要一个能够快速处理大量内容的系统,因此,我们使用了 RabbitMQ。但我们还需要一个简单的系统,该系统在软件层面支持设计和查询(查询所有内容,然后解析并显示)以及以内置方式提出 FIFO 的能力。为什么不采用切实可行的方法来集成一项与 RabbitMQ 配合良好的现有技术,而不是从头开发新的队列解决方案来解决我们所有的需求呢?这就是我们选择 Redis 的原因!
我们引入了复制所有指令的新流程:一个在 RabbitMQ 中用于处理,一个在 Redis 中用于监视/编辑
当一条消息进入 RabbitMQ 时,相同的某条消息会以 FIFO 方式放入 Redis 集中。当任务处理程序处理队列时,它们还会在 Redis 中移除/放置消息,让我们的集合与 RabbitMQ 同步。
接下来,我们开发了一个 Web 界面来控制和显示 Redis 中的内容。它还可以通过带有到期时间的 Redis 值来控制队列的状态,该值告诉任务处理程序是否应处理该队列(我们可以在不停止任务处理程序的情况下暂时停止某个队列的处理)。
为了记录,一个全局事件每秒可包含多达 10-20 条消息(对于 1 个展位),并且我们在全球各地都有展位——但由于Redis Enterprise Cloud的强大功能,可以进行扩展!
不同于一些仅仅显示人物头像的应用程序,Silkke 面临着展示动态角色动作的挑战。比如,头像需要散步,并且通过聊天和发送消息进行互动。尽管市场上已经有一些适用于多人支持的解决方案,但没有一个能够符合我们的需求——尤其是在服务器端。我们面临的主要问题是如何将游戏中一个头像的显示与其他头像进行同步。
答案:房间。
如用于文本的聊天室,我们需要一种解决方案来注册当前存在的头像。至于之前的问题,我们可以在同一时间拥有三个头像或数千头像,但仅出现随机连接高峰。
幸运的是,Redis 再次拯救了这一天!我们可以创建房间,为每个连接到该应用程序的人存储头像 ID。架构很简单:为每个人设置一个集合。但通过对它进行基准测试,我们想到了一种新的实施 Redis 的方法。如何使用它来实现聊天系统,使用发布订阅系统和套接字系统?然后一切都变得非常好了。我们可以在一个房间里处理 5,000 个人。并且与其仅将其用于文本消息,它还可以用作命令的中继。
比如说你想让你的头像去酒吧喝一杯。你从你的手机上点击“喝一杯”,就是这样。但在底层,Redis 展示了它的强大功能。在不到一秒内,它检查了你的身份验证密钥,检查你的头像是否在场景中且已连接,发送前往酒吧的指令,检查该指令是否正确启动,并通知你。这一切都依靠发布订阅、过期以及哈希表实现。然后我们可以将其扩展到你在图片中看到的每个头像。Redis 再一次完美地满足了我们的需求。
现在,还有一些项目在构思阶段,在解决速度、可靠性和可扩展性问题时,Redis 至关重要。
要快速开始使用 Redis,你可以免费注册 Redis Cloud: /redis-enterprise-cloud-free-30-mb-plan