在1.对于发布商品和交易的总数的时候，数据库的设计：因为对于发布者发布的总商品和交易的总数，这部分不仅仅只是涉及到用户表，同时也涉及到商品表，那么在我的二手闲置商城中，为了确保系统的性能以及可扩展性，不应该盲目尊崇数据库设计的范式，而是实现数据库表的yonyu字段，使其反范式化 那么分析一下，第一版我对于商品与用户的表设计时，考虑的是在商品与交易表中实时的通过count去计算我们的商品数，这样在用户界面时查看自己的交易与发布的商品的时候，能够实时的去计算和查看我们的发布的商品总数和交易总数，但是这样也带来了一系列问题，如，当我们用户不断的去发布商品和交易的时候，对于我们的数据库带来的性能压力是极大的，可以想象，当用户的商品积累至万级时，所损耗的性能了，每次访问都需要计算对于初期是可以的，但是并不优雅​那么我的第二版解决方案是什么呢？ 即在用户表中实现插入yonyu字段，将用户发布的商品使用计数器的形式去写入数据表中，这样，我们就可以通过查询用户的字段即可实现读取交易总数和发布商品的总数，但是会出现什么问题呢？每当用户发布一个商品或完成一笔交易，都需要更新 `users` 表中的这个计数字段。这会导致对用户表的高频写入，在高并发下容易产生行锁竞争，影响核心用户服务的性能。​但是对于我的这个小平台而言，这已经是比较好的一个设计方式了，对于业务增长没有怎么大的情况下，这可以应对1000-2000人的使用。但是，作为一个优雅的程序员，我已经在这部分埋点了，这部分后期我需要去实现第三版优化。具体的优化方式为：​在深入了解了EDA，RabbitMQ的底层原理，我可以确定的是，我们完全可以去是实现一种读写分离，并且考虑最终一致性的一个设计模式，对于微服务而言，我们并不需要去对商品，用户，订单服务进行额外的增加yonyu字段，而是可以去考虑在用户行为模块中，实现DDD架构中的聚合模式，想象一下，目前我的商品模块在发布商品的时候，已经实现了RabbitMQ的异步发布机制，当然，这部分的商品发布机制对应的只是个性化推荐系统的商品推荐，那么我能不能在用户行为模块中实现一种消费机制，实现用户的发布商品与交易商品的回显呢？当然可以，用户的行为模块是关于收藏，点赞发布评论，这些都是可以实现异步机制的，我们不需要实时的去显示，而是为了考虑最终一致性而设计的。

    bro也不知道啊，bro六级没考口语。    hr面让我英语自我介绍和英语介绍实习经历。哑巴英语破防了我。    下午电话面试，然后先是hr面再技术面。hr面上来就让我英语自我介绍。看得出我的窘迫hr还特别好心的给我五分钟时间准备。    然后介绍实习经历的时候听得出我的垃圾英语不行，然后让我可以用粤语介绍的。    公司主要语言是粤语和英语。    感觉寄，他后面用词特别谨慎，十分强调“有可能会有技术面试通知你”。刚说“过了的话”然后秒改口“如果过了的话”。细！    bro一定努力学英语，睁眼看世界。    后面问期望薪资，bro也很狂妄的说12k到15k年，月10k左右。实际上压根没想过。。。    下一次bro一定好好准备这种问题的回答。

在我大一大二的时候，说起就业选offer，只想找个钱多事少离家近的工作，当真正开始做选择的时候，已经不仅想找钱多事少离家近，还想要找一个福利好，地理位置好，稳定又发展好，公司文化好，不加班，上手容易，领导不错，公司又大自己还喜欢的工作。但更现实的时候，只能在烂的工作中挑一个不那么烂的，在众多不喜欢的工作中排除实在接受不了的工作后再选看着能接受一点的那种

当你看到通知时，职位已同时处于「存在」与「消失」的量子态🔮❓