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

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

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

25老东西本来已经打算出去爽玩了，今天突然收到这家公司的面试邀请，有没有牛油知道这家公司啊，要不要把机票退了去面试呢？PS：已收到4399开发，深圳电信运维offer, 有点折腾不动了引流：华为，腾讯，美团，京东，字节