估计有 number 有 string

@Feedline 想用 公司不支持这个

@airfling 不一定存内存里啊, Redis 只是为了方便, 你存 MySQL 里, 加上索引, 不也可以吗

@yxjn 不太懂为什么同样的消息要按照不同的权限区分.我的理解同一中消息就应该放在同一个 topic 里, 然后客户端权限验证可以走别的,比如接口鉴权, 发现自己没有读对应消息权限之后, 就不要在消费了. 发现有了新权限, 就开始消费.

@ebingtel 还好 Redis 也可以不是单机 分库分表嘛 具体的消息不要存进 Redis 存个 ID 就行 主要是必须解耦 容灾 可扩展 消息还最好只消费一次 后面这些要求任何一个消息队列都比现在的 Redis 实现要好

当然做玩具或者小公司不用考虑这些

@Varobjs 多谢 跟 sqs 很像 不过看到基于内存的 可靠性可能要打折了 还没具体看 上班研究一下

@Takamine 性能会有问题 分布式的东西还是应该让队列做

惊艳

kafka, 创建不同的 topic, 然后每个 topic 创建多个 Partition 就行了

初始化全量更新, 可以将这些数据先写到流里.

现在用 go 的很多 多用工程化思想去写代码
比如有 err 就要想一下怎么处理

你是想让一个地方登陆, 整个系统都登陆?

你们这些都不看错误怎么处理的人 能写出什么严谨的程序

这个题我觉得没描述好 应该改成需要用户实时看到结果
要不然做成批次（够 100 人开一次奖）或者 200w 人都参与完在开奖就太简单（技术上太简单了 我会认为这公司很水）

@woahishui 每秒就 10 个人抽奖.难道让他们等 10 秒才知道中没中？
@NewDraw 200w QPS 过来 服务端延迟多少？ 分布式机器怎么从队列取数据决定谁中奖？
@CRVV 这个思路不错 不过为什么要路由到同一台机器？那台机器挂了呢 扩容了呢？ 抽奖结束直接记录信息是不是更好 还有这个算法太简单了 可能抽不到 200w 所以要参考微信红包算法

@rming 为什么存不住 不结婚买房吗

傻 d 你一个人代表男人了？

Em....我技能树跟这个一模一样 不知道怎么描述 多谢楼主 抄走了
另外我还熟悉 aws DynamoDB ElasticSearch 服务治理 搭建新服务啥的

@cool007zqw 羡慕你