dddbbb's recent timeline updates dddbbb's recent timeline updates |
dddbbbV2EX member #439383, joined on 2019-09-03 11:28:51 +08:00 |
| [Rust] 新加坡 Sea Group 集团招 Rust Go 中间件研发 酷工作 • dddbbb • Apr 2, 2020 • Lastly replied by JoeSmith | 35 |
dddbbb's recent replies
Dec 23, 2019 Replied to a topic by dddbbb › 酷工作 › [Rust] 新加坡 Sea Group 集团招 Rust Go 中间件研发 |
@wayslog 代表公司就不用私人账号了
Dec 19, 2019 Replied to a topic by dddbbb › 酷工作 › [Rust] 新加坡 Sea Group 集团招 Rust Go 中间件研发 |
@freelancher 有的
Dec 18, 2019 Replied to a topic by dddbbb › 酷工作 › [Rust] 新加坡 Sea Group 集团招 Rust Go 中间件研发 |
@daby 目前没有这样的部门
Dec 18, 2019 Replied to a topic by dddbbb › 酷工作 › [Rust] 新加坡 Sea Group 集团招 Rust Go 中间件研发 |
@daby 请问你指的架构部门是？
Dec 18, 2019 Replied to a topic by dddbbb › 酷工作 › [Rust] 新加坡 Sea Group 集团招 Rust Go 中间件研发 |
@EricNirvana 这个是纯内存的，做持久化要保证性能和稳定性的话复杂度会高很多。
我个人非常看好新加坡这边的市场，东南亚互联网业务是全世界唯一的超级大蓝海了。而且华人过来完全没有陌生感。
我个人非常看好新加坡这边的市场，东南亚互联网业务是全世界唯一的超级大蓝海了。而且华人过来完全没有陌生感。
Dec 17, 2019 Replied to a topic by dddbbb › 酷工作 › [Rust] 新加坡 Sea Group 集团招 Rust Go 中间件研发 |
@luozic 没有上 dpdk，目前先只是实现快速动态扩缩和自动化运维。
Dec 17, 2019 Replied to a topic by dddbbb › 酷工作 › [Rust] 新加坡 Sea Group 集团招 Rust Go 中间件研发 |
Dec 16, 2019 Replied to a topic by dddbbb › 酷工作 › [Rust] 新加坡 Sea Group 集团招 Rust Go 中间件研发 |
@HarrisonZ 没错，“正确”的做法是 cache，persistent kv store，queue 做成三个分开的产品。
我们目前有的是高速伸缩的 distributed cache，支持 pub/sub 更多是迁就业务的妥协。在没有统一框架统一技术标准的情况下比较难做到让不同部门去适配同一套中间件的使用标准。
我们目前有的是高速伸缩的 distributed cache，支持 pub/sub 更多是迁就业务的妥协。在没有统一框架统一技术标准的情况下比较难做到让不同部门去适配同一套中间件的使用标准。
Dec 16, 2019 Replied to a topic by dddbbb › 酷工作 › [Rust] 新加坡 Sea Group 集团招 Rust Go 中间件研发 |
@HarrisonZ 这个是不同的产品了
Dec 16, 2019 Replied to a topic by dddbbb › 酷工作 › [Rust] 新加坡 Sea Group 集团招 Rust Go 中间件研发 |
@pipi32167 Redis 总体来说就是一个舍弃强一致性然后追求低延迟的中间件，所以你看现在所有的方案都是往这个方向靠的。
比如官方 Redis Cluster 的 pub/sub 也是靠节点直接广播 publish 请求，吞吐量可以横向扩，但是不保证在挂节点的情况下所有连接都能收到消息。我们也一样，希望是 at most once。然后 Redis Cluster 直接不支持事务，lua script 也是必须用户保证 key 都在同一个节点上。
这个事情不是说不能做，而是用 Redis 做通知或者队列服务的大部分不会强依赖中间件本身的消息 100%可达，而是服务本身做补偿，或者在业务上在挂机器的时候丢少量消息在业务上是可以忍受的。如果对队列本身有更高要求，会直接选择用其他中间件。
比如官方 Redis Cluster 的 pub/sub 也是靠节点直接广播 publish 请求，吞吐量可以横向扩，但是不保证在挂节点的情况下所有连接都能收到消息。我们也一样，希望是 at most once。然后 Redis Cluster 直接不支持事务，lua script 也是必须用户保证 key 都在同一个节点上。
这个事情不是说不能做，而是用 Redis 做通知或者队列服务的大部分不会强依赖中间件本身的消息 100%可达，而是服务本身做补偿，或者在业务上在挂机器的时候丢少量消息在业务上是可以忍受的。如果对队列本身有更高要求，会直接选择用其他中间件。
Select Language