@luozic 没有上 dpdk，目前先只是实现快速动态扩缩和自动化运维。

@pipi32167 有运维成本

@hahajing2019 有体现深度的项目经历也是要的

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

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

@HarrisonZ 这个是不同的产品了

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

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

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

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

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

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

我们在招 rust，希望各位了解一下：
https://v2ex.com/t/628803

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