set 是可以 set 成功的，但是 get 会报错，json 序列化也是可以看到有值，是个坑

看项目前景吧，是否赚钱，是否有挑战，还有你的直接领导人品，团队协调能力，方向是否正确，不只是光看浅那么简单

真的觉得人生太苦啦，如果再选择一次，很多人估计不会来了，很多东西以为努力就会付出就会有收获，其实很多努力是没有意义的，社会太浮躁，周围人都在攀比，很难静下心来做事，特别年过三十，你渴望三十而立，渴望成功，谁不知道，但凡你做错一件事，或者做错个选择，你的人生基本固定在哪里，面对父母年老体衰的的情况，伴侣的诉求，婚房，彩礼，教育，每一样都要你操心，你根本没有时间去思考你的人生的意义何在，你的兴趣已经多久没捡起啦，只有钱，你才有安全感，只有钱，才能让你有自信，这根本不是你想要的生活。可是你只是个普通的人，为什么要承受那么多。。。又要你情商高，又要你赚钱，又要你八面玲珑，不能有脾气。。。。。。

小公司没那么多资源，很难搭多套环境，都是共用一个 test 分支

大多数的服务都是 io 类型，而非 cpu 类型，每个容器都需要 redis 和 mysql,不扩展 mysql 和 redis ，就是做个服务隔离，我觉得没太大意义

不推荐，找个专业的培训机构或者老师，自学还养家糊口，压根没有时间自己学习

@meta 一个是获取用户各消息类型的未读消息数，一个是获取各类型的消息列表第一页（按时间倒序），分区的话都要建立这两个索引，代价是索引越来越大

@MoYi123 写应该没什么问题，就是如果系统刚刚好有一个用户是客服，然后很多人都给他发信息，堆积消息未读数有十几万条，基本上扫索引也很慢的，因为 readstatus 就两种状态，基本上索引也要全扫描，后面改成扫描 100 条显示 99+算是个比较偷懒的方法

@npe 也做了这个优化，select count(1) from (select 1 from sys_message_user where user_id = :userId and `type` = :type and read_status = :readStatus limit 100 ) t

@zoharSoul 就是看看一般是不是这样做，现在采取的是分区方案

1.看面试岗位决定，不可能一个基础开发问架构的问题
2.无论面什么岗位，基础一定要问问题，那些说很久没碰代码忘记了这种肯定有水分，上次问过后端 mysql 无符号数和有符号数都的区别都不知道
3. 问对方擅长的东西，看看真的是否擅长
4. 问自己擅长的东西，看看对方知否知道
5. 问自己遇到的问题，看对方也是否遇到
6. 问对方项目遇到的问题，如果没什么问题基本上做的项目没什么深度或时间不长
7. 上面如果还是觉得不靠谱，建议出个笔试题考考对方

1. 大道至简，接口测试是个方法，你可以可以控制方法责任分明，变得容易测试
2. 抽象业务，考虑扩展，你的代码是否支持
3. 结合生活场景，理解代码架构
4. 不要为了设计模式而设计，把命名写得简单明了就已经很不错了

@stach 嗯，现在另开一张表记录这个佩戴信息

@lingalonely 其实就像现实中超市积分兑换礼品一样，超市肯定那边有记录你兑换了什么，然后我们就得到一份随身物品，这个物品用户身上也可以记录的，所以最好两边都有这层关系，所以现在打算就这么做了

@qingshuang 我也觉得，不考虑成本，拆的话肯定最理想，只是机器有限，成本有点高，现在打算流量大的服务才拆出来

@libook 流程是不是可以这样理解，用户兑换积分购买头饰的时候，积分服务调用饰品服务，给用户加头饰，然后用户信息查询是否有佩戴头饰的时候，需要调用头饰服务判断，相当于多了一个中间服务，这样理解没错吧

你要记得你只是幸存者偏差，这这个时间点当上了程序员这个行业，并在这个行业赚了点钱，但是你要看其他行业的工资水平，不是说是你努力了就有结果，时间不等人，2015 年的房价到现在翻了两三倍，到了你成家立业的时候，父母面临退休，体弱多病，你面临结婚生子，事业上的瓶颈，你力不从心，而房价更让你掏空一切，你觉得正常吗，这个社会不应该这样，把年轻人的梦想都扼杀了，国家在大局上割一大帮人韭菜来透支 30 年去奉献 gdp,你看上去国家肯定会成为世界第一，而你对自己的未来看不到希望，这才是最可笑的。

最没有想到 30 岁的你活成了你自己讨厌的样子