过来人的经验，不要让双方父母住一起，还有一条，尽量避免婆媳长期住在一起

这两年确实体会到了写日记可以缓解内心的焦虑，让内心能够恢复平静

上个月出差在北京呆了一个周末，周末没事就去找个地方看电影，两件事情让我对北京有了新的认知
1 、看完电影，到中午了，想找个地方随便解决一下午饭，我一路走了 3 公里才找到一个吃饭的地方，这还是在海淀。这事情放在南方哪个城市都不可能发生，因为电影院基本就是在商场，出门就是各种餐饮（另外北京的电影院的硬件确实很陈旧）
2 、我沿着西土城路走，尽然看到了一个光秃秃的小土坡，没有一点绿化，这个在一线城市的核心区域应该很难看到这么大面基的小土坡，至少怎么也得种点四季绿的植物

通过上面我能够感受到，北京生活的便利性确实和大部分一线城市不太一样，另外就是环境层面，也是相差比较大，就我一个南方人的角度看，我是无法在北京长期居住的

可以去春熙路做手工

看上去这个部门恨厉害的样子

@Aidenboss 看来研究的开源项目不少，来不来我们这边搞事情？我们这边是搞基础架构的

@Aidenboss 那你是如何解决消息消费者消费到一半，宕机或者重新部署，消息不丢失的？如果你不记录消息消费位置的？

@Aidenboss 是否通过真实的大规模场景验证你的这个方案？如果没有，如何验证你的方案是真的可行？
第一：首先采用 redis 方案，看似把最难解决的消息存储交给 redis 已有解决方案来去解决。但是在真实大规模场景下，这会导致网络开销增加了一倍，因为多了一次 center 和 redis 的 request/response 。这种网络开销在亿级别的消息体量下，会严重影响性能
第二：整个集群管理你如何保障？如何让全局感知整个 topic 分片的负载策略？以及当出现网络异常（你的 stop 命令都无法发出的时候）如何保障集群的一致性？以及消息的消费顺序如何保障，如何记录消息消费到了哪里？以及当消费端重启的时候，如何找到之前的消费位置？

只能说你在逐步完善一个消息消费的最基本能力（消息通信），但是对于一个简单的 MQ 场景来说，这只是最简单的部分

@Aidenboss 那整个架构 redis 将会是单点，虽然你的 center 可以通过 niginx 负载，但是如何解决单个 topic 消息量倾斜，导致 redis 集群负载不均衡，如果基于 redis，那 topic 的负载如何基于 reids 来实现，是你这个能否规模化的关键，至少这里没有实现或者体现。

如果想真正研究大厂的基础架构，欢迎加 Vbieber-cn，来我厂一起搞事情

@Aidenboss
1 、你这里 99.9%的可用率在亿级别场景肯定达不到，首先你的 center 如何做到容错和负载？这一点你的架构一点都没实现，怎么保障你说的三个九的可用？至少机器挂了你这一点容错能力都没有。
2 、你这里不只是 redis 水平，还有你的 center，你的 center 只是单点？单点你就敢承载亿级别的场景？太异想天开了。如果你 center 要做分布式，那就涉及到 center 的发现和负载，以及 center 和 redis 之间的归属如何分配？不是你想的这么简单。

学习角度我是赞赏的，但是不要那这个去做实际生产场景，赞赏你的分享精神，但是如果你想证明自己，请把这个东西做到你说的三个九。如果这样简单搞一下就保障了三个九，你以为大厂哪些人是吃素的？

@huyujievip 加 VX：bieber-cn

多看源码（中间件源码，框架源码，项目源码，JDK 源码），多写代码（可以将看过的开源项目自己写一遍），多思考，多总结。

所有的有点都是自己 YY 的，你有相关一个系统引入一个新的组件带来的各种风险吗？你能确保你的这个组件有多少个 9 的可用性？以及面对真实的生产场景，面对上亿的消息量，你的 redis 机器，和你的 message-center 集群如何实现横向扩展？能否通过简单的加机器就能解决？我看现在你的架构都不具备。你当前的架构就是一个 Toy，练手我觉得可以，但是千万不要用于实际业务场景，否则业务会被害惨的。所以上面说的第一点，纯属自己 YY，当前哪个消息中间件整个稳定性和横向扩展性没有 99%以上？请用成人思维去思考。

架构的本质是去繁化简，多增加一个组件和一行代码都是需要经过仔细思考的，所以你上面说的第二点，无疑是为了自己的技术热情而引入的没必要的架构复杂度

欣赏你对技术的热情，可以作为技术分享对你的技术理解，但不要轻易的将自己的东西当做框架或者开源推出去，这是一种对技术不负责任的态度。

现在的开发真的是啥都不会呀？一上来就是 springboot，又是 springcloud 。啥 j2ee,jdbc 都不会了？原来至少 struts2 和 springmvc 还能感受一下底层，自从各种 boot 出现之后，大家应该都不知道 web.xml 里面长啥样了吧？建议还是沉下心来去看看基础，不要整天浮在各种框架之上，不然你永远不知道这个世界是怎么样的

这个库纯属你们老大闲的没事，没有任何技术含量。
数据库访问不管是 spring 现有的框架 spring jdbc 还是 mybatis 都已经很完善，没有必要自己再去造轮子，
http 服务器这个是啥意思？自己做了一个 tomcat ？还是 nginx?如果是，那这个轮子太重了，闲的蛋疼，如果是一个统一的 springmvc 包装，这也是闲的蛋疼，没事找事。
授权签证，这个不管是 spring 的 security 还是 shiro,结合 oauth 规范，这个也没必要再造一个轮子；
卧槽，为啥用户系统还做成了一个框架或者工具？这明显是一个业务，业务就要好好的去写业务，没必要在搞一个这个东西
TCP 现在一大堆网络框架，为啥自己写？你能比 netty 牛逼？如果是这样，那他现在也不应该还在你的公司，早就名声在外了。
综上所述，你们公司太卷了，而且卷的一点技术含量都没有，来我们这边[狗头]

现在这种网络层的框架太多了，如果是自己练手，比较认可，抱着学习太多去了解更多技术细节。但是如果要让更多人用，那需要回答你和现有的框架有什么差异和优势？比如 netty,mina 。

业务开发里面就是各种 O 之间的转换，越复杂的架构，这种 O 越多。所有的性能损耗都是在 get/set 里面，90%的逻辑都是 get/set.

单一职责原则，架构分层原则