struct 建议存 pointer，方便直接通过 map[x]修改

第一级如你所说是 DNS 实现按地域分配二级 balancer 节点，第二级一般是 Nginx/F5/LVS 实现单区域数据中心的 API 网关（ HTTP/WS/TCP..）流量均衡，第三级一般还有一个 API 路由层负责对该 DC 业务集群的负载均衡，这里可以理解为 docker/k8s 集群=路由层+业务集群，再往下就是 DB 层的分流，sql/nosql/ob-sql，不同的 sql 再做 master-slave, sharding, replicats，负载均衡差不多就是这些，高并发业务中除了 lb 还有一个重点的点就是 cache 。

@qile1 标准库有的它都有，get/put/qsize/empty/full/task_done/join, +reset

学了 go 你也不会丢掉 php，都有各自的适用场景，如果说职业方向的话，这就要看工作年限和个人兴趣了

搜罗一下，没找到做这个事的 pkg，做吧，有市场！

你往深了看。
令牌桶的原理是通过控制桶内令牌数量控制并发，相当于是一种调节 /调度机制，这种调度机制实现了限流的功能。转过来看看 brpop 这种方式，上游仍然可以通过 lpush 的频率控制下游执行的速率，这里是不是异曲同工呢，其实是实现了一样的功能，所以我说后者也是一种调度机制，用了 redis 就是做全局(分布式)的调度，同样可以不用 redis 而使用编程语言内部的队列框架实现这个机制（单机）。golang 的 GPM 模型比这个复杂一些，它的上游是操作系统(调度器)，下游是 goroutine，goroutine 需要调度器分配 P(processor)和 M(内核线程)才能执行，否则就等待。

你这个不是锁了，而是把 redis 当做调度中间件了，只有从 list 中拿到数据的 process 才能往下执行，没有就阻塞，就类似于令牌桶算法或者 go 的 GPM 调度模型。

@onice 贴图完整点嘛，看了首页图才明白你的意思。虽然可以把每级分类都作为字段，但这样不够灵活，特别是当有些商品只有 2 级分类，而有些商品增加到 4 级甚至更多分类的时候，这里通过 parent_id 的方式会更节省字段和灵活一点，要说递归查询的话也不会有多少速度影响，毕竟你的场景是商品分类，分类不会是无限级，分类表数据不会太大。
这样做的话
如果要查询 A 分类下的所有商品：
》根据 A 分类递归查询到最深层的所有分类 id 集合，然后使用 in typ_id_sets 查出所有的商品即可（商品的分类 id 字段表示最深层的分类）

三级体现在哪里？不是商品有个属性而已吗，分类，颜色，布局，语言四个字段，没理解对？

你自己想下就知道了，嗯，往不好的方向想

@Dreax https://www.jianshu.com/p/e0c3a3243830

你这个场景其实是树形权限表结构，不太清楚你的表是如何设计的，按我的想法一个接口就可以了，接口的参数就是用户 id，查询订单的时候，订单有个商家 id，商家 id 可能有上级，在用户表中有个字段叫 father_id 表这个人的上级 id （当然这样设计需要限制代理商最大深度），查询语句：select * from order where agent_id in (select id from user where id=2 or father_id=2)，这是最多两层的情况，如果有三个以上的层级，就需要递归查询把所有的 agent_id 拿到，再去查订单表了，如果是无限极那又是另一种处理情况了。。

@GM 你说话比较尖锐，当然，我觉得是一针见血了。

哈哈哈，严肃脸。

米粉卡吧换，尽用，3 元 1 天不限，一个月流量费不过 90。

下家公司慎选

花时间复习一下面试题，抱抱佛脚还是可以的

@realpg 好吧，只能说确实太少见了，这得是多大的项目规模了

对于 ws 服务端来说，一台普通服务器倒不是说承受上 w 个 client 连接无压力，这个还要看消息 size 和传输频率，几十万人直播间那种一台机器的网卡都受不住了。