NUT

我看完还是觉得楼主可以。 我想法是能不能 用 mvp 方式先进行验证。 当然时间也是一个成本。

通用问题。 其实必须有一个主去做 session 状态的分配。 陌陌老早时候有一个 ppt 分享他们的策略。 分三层，一层是接入层， 无状态，可以任意扩展，主要是接受链接， 第二层 逻辑层，保证消息业务逻辑的路由等， 第三层存储。

其实你的服务没有脑子，需要有一个脑子，去做这种订阅关系的维护， 也就是 接入层上线以后， 由 master 去做分配 session 相关策略。主要保证 master 强一致就行。

不过咋说，难度就会上一个层级。 还可以看看 codis 还有 tidb 等分布式设计。 会有帮助的。

西安 上周五 45

@lbllol365 #17 找不到了，https://github.com/kuangye098/rocketmq 看看这个。 或者找下 3.x 版本的 RMQ

建议你看下 RocketMQ 的早期的版本大概 18 左右的。
能学到非常的东西，比如 mmap zerocopy （ netty ）还有一些包括 java 并发类。比如 CountdownLatch2 之类的。
对了还有 RPC 协议，这里面又有 oneway async sync 调用等具体实现。
当然还有核心的 NIO channel 读文件之类的， 也能明确的看到啥时系统刷盘的实现。

源码其实不用看的特别对，只要精通看几个典型的，就行，开始看的就和进入大观园一样。 啥 tmd 的都不懂，慢慢刷。刷上 tmd 的几个月肯定有效果。

说一句 RMQ 的代码基本没啥注释，我当时都是手动补的。可惜的是换电脑，代码找不到了。

如果你想对 netty 的极限应用的了解，可以看下 zuul2 的代码就是那个 http 网关， 一个是 paasport 的 debug 设计，一个是一个调用链不同 handle 的不同玩法，一会添加，一会删除的。 哈哈哈哈 简直不要太牛逼。

配置中心可以看下 disconf 挺经典的。 而且代码比较精炼，看懂这个基本上 spring 容器基本咋玩就知道了。ps 我抽了 disconf 核心，18 年改造成 starter ，然后陆续的给其他中间件适配，比如 redis 、mongodb 啥的 从 17 年用到现在，也没啥问题。 后面 18 年我们接入了 dev-ops ，上了 k8s 他妈的动态配置需求砍掉，直接滚动更新，比啥都香，就是点点鼠标的事情。

java 好轮子太多了。 深入死磕几个比啥都香。我觉深入看源码坑还是很深的，不好坚持，如果受不了那种苦，我还是劝退吧。去做点业务也不错。

不过咋说，还是建议能够对代码有一个非常深度的了解，这好比，你从一开始选择「简单指令集」难度必然大于「复杂指令集」。不过后期的灵活性，是很大的。

当然这个也与个人的个性有关系，如果你是那种「长期主义」愿意牺牲一点短期利益，去坚持做一点事情。我相信总有一刻能真正的体会「量变引起质变」。

一个 java 老菜狗。不喜勿喷。

和 authing 差不多。

说缺的不是好点子。
缺的是 落地方法。

我也知道发射商业火箭很挣钱啊， 不过没法落地。

其实就是那种 影响圈和 关注圈的概念。

努力扩大影响圈，去在影响圈掌控足够的话语权。 一个个落地。

我并不觉得奇思妙想有什么价值？！ 中国牛逼的人都在闷声挣大钱。到处 BB 的人要么是韭菜，要么是割韭菜的。

一个好的想法，其实你思维的一个实例投影。 并不是一个完整的可执行的计划。

「知行合一」吧。

比较好奇楼主用什么语言栈写的？

@djokor #5 要考虑利润 bug 修复 之类的。