@wangxiaoaer 你这个问题，要结合业务场景来讲。就说订单这个东西，如果你的用户少，可以不做拆表处理的。当用户购买商品后，去查询订单，这个请求是个读请求，而且查询可能根据时间，状态过滤。这个列表数据是不容易做 memcahced 缓存的，所以，必须将这部分查询请求放在从库上执行。这样主库的压力就会降下来，放几台要根据你的 qps 量进行估算。如果每秒有 2w 笔查询，那你单台能支撑的是 5000qps，你就需要准备至少 4 台服务器。如果你再能在应用层将请求分割开，那么每台的 mysql 可能只负责某个区域的用户查询请求，那么 mysql 的 buffcache 就可能非常高效。

LDAP 的 class 结构是用来做标准化数据的管理的，例如通讯录，产品规格信息的。你这种非标的东西根本不适合用 ldap。除非你是想利用 LDAP 的目录复制功能，分布式的复制目录的信息。

大部分的查询请求，其实不用那么实时，例如订单完成之后，可以不用变化。而且 mysql 的复制还是非常快的，100 毫秒上下，这样主库就可以把 cpu 剩下来提高写入的 ops。

我觉得你想要减少 redis 的写入量的话，加一套 kafuka，让数据先落盘，然后再用流处理，合并一些统计，减少写入的次数。

不用换语言，收效不大。优化你的数据，尽量让热点数据能分散开。cpu 峰值长期不要超过 60%，经常 80%已经明显有风险了。

好想后面的剧情就是在 QQ 上联系你，给 500 块的话，把密码还给你。然后，就是还的再加 500，再加 1000，再拉黑你。

假设存在 100 万你说的这样的小姐姐，那么单人估计的年收入是 50w，那么一年这 100 万人创造的收入是 5000 亿。一个烟草一年才有 1.7 万亿，你觉得可能吗？

人类社会的进步还是靠技术推动完成的，而不是什么国王和圣贤推动完成的。短期看，目前世界范围内，还没有新的技术突破，所以，目前应该是个存量市场。996 还是不 996，无非是用下属的血去表衷心，染红顶子。

@gramyang 我对 netty 不了解的。好像两者没有差别，除非是 ctx 上的 executor 被替换了默认的实现。

netty 这种东西就是异步 IO，也就是在 decode 时，已经完成了数据的接收。decode 只是利用 cpu 做一些计算完成 byte 的转换。cpu 干这种事情是非常块的，也不需要其他子源参与。一旦你做完了 decode 得到了需要的 java 对象，那可能你会去做业务处理，例如数据库的查询，这里会阻塞 worker 线程，那么另外的连接就必须排队 decode，所以，要想让并发量高，你需要用另外的线程池去干业务的事情，或者分发给其他的服务器来做。

50 一小是很容易挣到的，你们读一遍文档，人家秒懂。

里面水平不是太高，未来是不是做这个职位上说的事情也不一定。

如果只是低水平的重复是不会提高技能的，出租车不管开多少时间，也成为不了赛车手。

不建议买，几个原因：1.车不保值。2.每年车需要保险，保养，停车费，油费，大概会超过 6000 元，综合使用成本在 1w。3. 建议成家后买，如果财务上每年能拿出 1 万多来养车，否则太浪费。

把修改商品的功能做成服务，用 RPC。