加牛不辣
加牛不辣
我在这个 pr 的基础上改造了一下，主要定义了页面的 JSON model，然后用 vue 简单写了个页面。 后端逻辑比较复杂，我就没怎么改。 可以看图
> 如果配置了apiserver地址和service account token，则apollo-client会把配置缓存到configMap去 这个意思是由 client 去写 configMap 吗？ 我的想法是由外部系统，比如 apollo-admin 或者别的服务将应用服务的配置写到 configMap 里。 应用服务的 deployment 里默认挂载自己的 configMap 到某个目录，apollo-client 到这个目录读取 这样 apollo-client 的职责比较简单，还是和原来的功能一样。 写 configMap 的逻辑是新增的，在服务端实现就行
不是说通过每台机器上留 buffer 解决吗？比如 100 台机器每台分配 105 张票，这样就有 500 张 buff 票，就能容忍 5 台机器宕机。 最后通过 redis 的统一库存就能保证不会超买这 500 张 buffer 票
> > 不是说通过每台机器上留 buffer 解决吗？比如 100 台机器每台分配 105 张票，这样就有 500 张 buff 票，就能容忍 5 台机器宕机。 > > 最后通过 redis 的统一库存就能保证不会超买这 500 张 buffer 票 > > 但是这个逻辑 localSpike.LocalDeductionStock() 是不是会导致少买宕机机器上的余票？ 为啥会少买？比如...
> 已经停止维护，请换用别的列表。 @wfjsw 有啥推荐吗？
redis 的单机性能是 10W 的话，这里就是假设同时抢一个车次的请求量不会超过 10W 吧，这样单台 redis 也能抗住一个车次的量。 如果这个车次很热门能超过每秒 10W 的请求量，那可能也可以根据车厢再分流？一个 redis 只负责一个车厢的，这样也能抗住。 所以重点思想还是用内存操作提高效率吧
> 如果能公开字典就太棒了，想做一个逆向转换 哈哈哈，我也想搞个逆向转换，让世界充满更多的魔法