• 外包信息请发到 /go/outsourcing 节点。
• 不要把相同的信息发到不同的节点
这是一个创建于 1841 天前的主题，其中的信息可能已经有所发展或是发生改变。
Hi:
这边是 shopee 和 garena 的集团总部 infrastructure 中间件团队，现在招中间件研发。 目前在用 Rust 和 Golang 做分布式 Redis。对这方面有兴趣的都可以聊聊。
希望你：
- 对底层技术有浓厚兴趣
- 熟悉多线程编程
- 熟悉 Linux 系统原理和系统编程
- 了解过分布式系统
- 有 Rust，Golang，C，C++的研发经验
你将会：
- 设计实现分布式 Redis
- 优化分布式 Redis
- 实现分布式 Redis 测试系统
感兴趣但没有相关经验的我们都可以聊聊，这边一位之前没有相关经验的同学两个月就上手了。
薪酬一般比国内高，税远少于国内，入职提供约 7500rmb 的换城市补贴。工作环境跟国内一线大厂一样。对英语只有读写要求，但能正常交流更好。
有兴趣的发简历到: [email protected]
 |
1
jangbi 2019-12-13 16:54:11 +08:00
前端有坑吗？
|
 |
3
Yc1992 2019-12-13 17:10:48 +08:00
两个月是在黑他吗哈哈
|
 |
5
xuecan 2019-12-13 19:43:30 +08:00
面了 shopee 没过， 在 sea 这边会有冷冻期吗？
|
 |
6
Mistwave 2019-12-13 20:05:34 +08:00 via iPhone
rust 也招的吗，厉害
|
 |
7
waytoexplorewhat 2019-12-13 20:13:25 +08:00
有兴趣，能否给个微信聊一聊，或者邮箱是你本人的吗？
|
 |
8
dddbbb OP |
 |
9
pipi32167 2019-12-16 10:05:59 +08:00
我比较好奇的是分布式 Redis 是要实现 Redis 的全集还是子集？
如果是全集的话，比如 pub/sub 这类消息队列的功能，分布式实现的复杂度很高，重新实现一个还不如用现成的。 另一个难点是运行的脚本涉及到多节点的话，需要复杂的调度策略来读取数据和执行事务，这个也很难。 即使是 sorted set 这样的有序数据结构，也涉及到多节点的范围查询，实现起来也不容易。 |
|
10
dddbbb OP @pipi32167 没错，这两个功能是最复杂的。
pub/sub 其实要看你打算提供什么质量的服务了，如果要保证百分百不丢消息，是很难的。但是如果只保证大部分情况下消息可达，其实还是可以做的。 事务这块也要看用户的需求，如果 lua script 所操作的所有 keys 只由该 lua 脚本读写，完全不会有其他途径读写，那我们可以改写 lua 脚本，用 hash tag 把这些 key 改写到同一个节点上。 然后所有 collection 不会垮多节点，只会存一个节点上。 |
|
13
pipi32167 2019-12-16 11:53:24 +08:00
@dddbbb 道理是这个道理，但是需求方不一定接受。分布式 redis 的应用场景是单机 redis 无法支撑业务的前提下需要多机扩展，这意味着业务量呈现一个指数级的爆发式增长，那么单机场景下的很多瑕疵，在多机场景下可能就无法接受了。这点如果不考虑进去，注定是个杯具。
|
|
14
dddbbb OP @pipi32167 Redis 总体来说就是一个舍弃强一致性然后追求低延迟的中间件，所以你看现在所有的方案都是往这个方向靠的。
比如官方 Redis Cluster 的 pub/sub 也是靠节点直接广播 publish 请求，吞吐量可以横向扩，但是不保证在挂节点的情况下所有连接都能收到消息。我们也一样，希望是 at most once。然后 Redis Cluster 直接不支持事务，lua script 也是必须用户保证 key 都在同一个节点上。 这个事情不是说不能做，而是用 Redis 做通知或者队列服务的大部分不会强依赖中间件本身的消息 100%可达，而是服务本身做补偿，或者在业务上在挂机器的时候丢少量消息在业务上是可以忍受的。如果对队列本身有更高要求，会直接选择用其他中间件。 |
 |
15
HarrisonZ 2019-12-16 14:04:40 +08:00
TiKV 上面撸一个 redis 协议兼容层不就好了。不过要舍弃一些命令的支持。而且完全不要 queue
|
|
17
HarrisonZ 2019-12-16 14:32:59 +08:00
@dddbbb 是的，但是 redis 本身就兼顾了 ks store 和 queue。
而且分布式 queue 和分布式 kv store 做法也不一样。你这是都要在一个里面做，还是分开做 我觉得分开还好做点，但是分开之后就又有很多成熟的开源产品，没必要造轮子了。合起来好像就是为了造个轮子。```` 做工程的话，要我我肯定搞俩服务来做～～～ |
|
18
dddbbb OP @HarrisonZ 没错，“正确”的做法是 cache，persistent kv store，queue 做成三个分开的产品。
我们目前有的是高速伸缩的 distributed cache，支持 pub/sub 更多是迁就业务的妥协。在没有统一框架统一技术标准的情况下比较难做到让不同部门去适配同一套中间件的使用标准。 |
 |
21
hahajing2019 2019-12-16 19:48:53 +08:00
目前是 python 开发岗，工作第五年，自学过 go 语言基础语法，仔细看过一个 go 后端+vue 的代码实现(有意转 go)；大学也学过 C++,要么
|
|
22
dddbbb OP |
 |
23
luozic 2019-12-17 13:25:57 +08:00
dpdk redis 的分布式版本？
|
 |
25
EricNirvana 2019-12-17 20:50:53 +08:00
这个轮子的流量超级大会挺有意思的，之前用 golang 给公司基于 rocksdb 写过兼容 redis 协议的 kv 存储，业余也在玩 rust，可惜坐标在坡上…
|
|
26
dddbbb OP @EricNirvana 这个是纯内存的，做持久化要保证性能和稳定性的话复杂度会高很多。
我个人非常看好新加坡这边的市场，东南亚互联网业务是全世界唯一的超级大蓝海了。而且华人过来完全没有陌生感。 |
 |
27
daby 2019-12-18 12:36:22 +08:00
架构部门招人吗
|
|
29
daby 2019-12-18 14:51:36 +08:00
就是负责架构设计的
|
 |
31
freelancher 2019-12-18 20:51:12 +08:00
要运维或者 mysql DBA 吗？
|
|
32
dddbbb OP @freelancher 有的
|
 |
33
wayslog 2019-12-21 11:17:26 +08:00 via iPhone
擦，阿星你改名了？
|
 |
35
JoeSmith 2020-04-02 08:59:50 +08:00
可以远程么？
人在北京，可以出差，但是不能 relocate. |
Select Language