[Rust] 新加坡 Sea Group 集团招 Rust Go 中间件研发

[dddbbb]

Hi:

这边是 shopee 和 garena 的集团总部 infrastructure 中间件团队，现在招中间件研发。 目前在用 Rust 和 Golang 做分布式 Redis。对这方面有兴趣的都可以聊聊。

希望你：

• 对底层技术有浓厚兴趣
• 熟悉多线程编程
• 熟悉 Linux 系统原理和系统编程
• 了解过分布式系统
• 有 Rust，Golang，C，C++的研发经验

你将会：

• 设计实现分布式 Redis
• 优化分布式 Redis
• 实现分布式 Redis 测试系统

感兴趣但没有相关经验的我们都可以聊聊，这边一位之前没有相关经验的同学两个月就上手了。

薪酬一般比国内高，税远少于国内，入职提供约 7500rmb 的换城市补贴。工作环境跟国内一线大厂一样。对英语只有读写要求，但能正常交流更好。

有兴趣的发简历到: [e-mail]

[jangbi]

前端有坑吗？

[dddbbb]

@jangbi 其他前后端 android ios 都有

[Yc1992]

两个月是在黑他吗哈哈

[dddbbb]

@Yc1992 这位同学还是很厉害的，只是之前不是做这块的。

[xuecan]

面了 shopee 没过， 在 sea 这边会有冷冻期吗？

[Mistwave]

rust 也招的吗，厉害

[waytoexplorewhat]

有兴趣，能否给个微信聊一聊，或者邮箱是你本人的吗？

[dddbbb]

投简历的同学注意了，需要你们的英文简历哈。
@waytoexplorewhat 是的，邮箱就是我。
我微信号是 hgx-doyoubi

[pipi32167]

我比较好奇的是分布式 Redis 是要实现 Redis 的全集还是子集？

如果是全集的话，比如 pub/sub 这类消息队列的功能，分布式实现的复杂度很高，重新实现一个还不如用现成的。
另一个难点是运行的脚本涉及到多节点的话，需要复杂的调度策略来读取数据和执行事务，这个也很难。
即使是 sorted set 这样的有序数据结构，也涉及到多节点的范围查询，实现起来也不容易。

[dddbbb]

@pipi32167 没错，这两个功能是最复杂的。

pub/sub 其实要看你打算提供什么质量的服务了，如果要保证百分百不丢消息，是很难的。但是如果只保证大部分情况下消息可达，其实还是可以做的。
事务这块也要看用户的需求，如果 lua script 所操作的所有 keys 只由该 lua 脚本读写，完全不会有其他途径读写，那我们可以改写 lua 脚本，用 hash tag 把这些 key 改写到同一个节点上。
然后所有 collection 不会垮多节点，只会存一个节点上。

[pipi32167]

@dddbbb 你这个实现都是坑啊，请牢记墨菲定律，会被用户骂坑爹的哈哈哈。

[dddbbb]

@pipi32167 系统设计都是取舍，强一致和低延迟不可能两者都有。

[pipi32167]

@dddbbb 道理是这个道理，但是需求方不一定接受。分布式 redis 的应用场景是单机 redis 无法支撑业务的前提下需要多机扩展，这意味着业务量呈现一个指数级的爆发式增长，那么单机场景下的很多瑕疵，在多机场景下可能就无法接受了。这点如果不考虑进去，注定是个杯具。

[dddbbb]

@pipi32167 Redis 总体来说就是一个舍弃强一致性然后追求低延迟的中间件，所以你看现在所有的方案都是往这个方向靠的。
比如官方 Redis Cluster 的 pub/sub 也是靠节点直接广播 publish 请求，吞吐量可以横向扩，但是不保证在挂节点的情况下所有连接都能收到消息。我们也一样，希望是 at most once。然后 Redis Cluster 直接不支持事务，lua script 也是必须用户保证 key 都在同一个节点上。

这个事情不是说不能做，而是用 Redis 做通知或者队列服务的大部分不会强依赖中间件本身的消息 100%可达，而是服务本身做补偿，或者在业务上在挂机器的时候丢少量消息在业务上是可以忍受的。如果对队列本身有更高要求，会直接选择用其他中间件。

[HarrisonZ]

TiKV 上面撸一个 redis 协议兼容层不就好了。不过要舍弃一些命令的支持。而且完全不要 queue

[dddbbb]

@HarrisonZ 这个是不同的产品了

[HarrisonZ]

@dddbbb 是的，但是 redis 本身就兼顾了 ks store 和 queue。
而且分布式 queue 和分布式 kv store 做法也不一样。你这是都要在一个里面做，还是分开做
我觉得分开还好做点，但是分开之后就又有很多成熟的开源产品，没必要造轮子了。合起来好像就是为了造个轮子。````
做工程的话，要我我肯定搞俩服务来做～～～

[dddbbb]

@HarrisonZ 没错，“正确”的做法是 cache，persistent kv store，queue 做成三个分开的产品。

我们目前有的是高速伸缩的 distributed cache，支持 pub/sub 更多是迁就业务的妥协。在没有统一框架统一技术标准的情况下比较难做到让不同部门去适配同一套中间件的使用标准。

[pipi32167]

@dddbbb 基于现有开源消息队列基础上开发个薄薄的 redis pub/sub 中间层不好吗？

[pipi32167]

@dddbbb 当然更正确的做法是认识到技术债的存在，早迁移早解决。