之前午睡的时候，突然惊醒就会导致心脏剧烈快速的跳动

@L299174105 已使用，为了避免并发时填了一个人的，我建议先回复自己的邀请码，然后再把自己上一楼的邀请码使用掉。

[71009726]

@Rwing 目前准备使用 SpanNetty 测试一下，然后在对比一下之前老哥们提供的那些。

@xingyuc 这个有点像是一个大而全的项目脚手架了。
@mmdsun 这个貌似适用于 Web 项目，需要进一步了解。

感谢几位老哥，我看了一下 SuperSocket 还算是比较合适的，本质上我需要的是一个异步的，事件驱动的网络编程框架。

接下来需要进一步了解它们的线程模型，因为改造现在的这个项目就是因为并发导致的线程安全问题，如果像 Netty 那样跟其中某一个 EventLoop 绑定，移除掉阻塞操作基本上就可以达到一个比较高的吞吐量，而且无须考虑线程安全问题。实在不行的话我可能需要直接用原生 API 再结合自己的线程池来进行控制了。

建议查询，一般如果在事务内数据库报错了，会导致事务回滚，显然 try-catch 不适合，你查询的话可以给到客户单更详细的信息。

是每一条数据的组合都唯一吗？还是某一个字段的值是唯一的？
一般如果违法数据库约束会有报错信息，你 catch 住相关的异常然后响应给客户端对应的结果就行了吧。

又要加班了，提前订阅事后复盘

@JKeita 在深圳，不过还没成家。在深圳想要买一套房子凭我自己目前的积蓄还差得远，也没想让家里面出钱啥的，本来也不富裕。

2012 年开始上班。
2013 年的时候裸辞在家里躺平了一年，期间学了驾照，跟家里的狗子培养了很好的感情。
2014 年重新找工作，去了深圳，面试了好几家都说为啥这一年没有找工作啥的。
现在是 2021 年，一晃眼快 10 年了，真是一点也不留情。

给一条数据赋值 ID 一般代表这条数据具有生命周期，也就是实体，随机性的 ID 生成优点是速度快，但是一般都比较长，短且紧凑的 ID 一般需要有一个单独的地方进行维护管理，因为随机会有重复的风险，毕竟这个状态我们需要持久化。

说一下我们之前做过的一个 ID 生成服务：不同实体的 ID，都是一个隔离开的空间范围，这个递增的空间范围需要由一个独立的服务来进行维护和管理。传入实体类型，也就是一个 Key 绑定一个 ID 的当前值，并告诉这个服务我需要多大范围的 ID，可以设计一个接口：

(start, end) nextIdRange(key, size)

其中 key （实体标识）和 size （获取多少个）为参数，用于获取一段 ID 范围，返回值 start 为起始值，end 为结束值。
客户端获得以后就可以在这个范围内进行本地递增。需要注意的是，这个接口需要保证原子性，也就是并发的时候不会返回相同的数据，每一次调用都将会导致内部维护的当前 ID 值发生变化。

客户端如果生成 ID 频繁，可以考虑优化为当剩余的 ID 快要耗尽时，另外起一个线程去预取下一批次的 ID 段（假设是跨网络的服务调用，ID 生成服务为一个独立的进程），保证 ID 生成不会受到获取 ID 这个操作的延迟影响，设置为多少合适则取决于实际的情况。

@hertzry 谢谢兄弟，始终相信会遇到对的那个人

@Arrowing 谢谢，已经走出来了
@adminharlem 谢谢
@sharkfu 这个网名随便起的，哈哈
@dongcxcx 看来兄弟也有故事

我还记得上次的失恋，给我留下了非常深刻的印象，意志消沉了好一段时间，人总是这样，总是失去了才知道对方的好。
生活中到处都是她的影子，起床是，出门是，吃饭是，甚至连一个城市名，一个地点，也都是她的影子。我觉得将来如果没有她的话，那么跟谁结婚都是一样的吧，很痛苦，也很煎熬。
已经无法挽回了，她走的很坚决，头也不回，我不是没有尝试过放下人格，低声下气去求她，换来的也只是冷漠与忽略。我想我甚至比不上一个陌生人吧。

她要的东西我那时没有办法给，她总是任性，其实到后面不知不觉中，每一次对话的结果，都是负面与伤害，其实何必做到这一步，我真的想让她过的更好，也很爱她，哪怕到后面她对我已经失望透顶，我想对她而言，我俩最好的结果就是放手与不打搅吧，祝她幸福。

故事的开始总是这样，适逢其会猝不及防。故事的结尾总是这样，花开两朵天各一方。断了联系，老死不相往来。

从灰色慢慢变得有颜色，我经历了大半年，直到真正的放下，直到我意识到生活还将继续。

用户服务（授权和用户信息）：Service B
A 活动：Service A1
B 活动：Service A2

首先你要知道用户是否已经参加了 A 活动，必然要把这个状态持久化吧，在你的第一个问题中，它是存储在 Service A1 服务上的。
现在有需求，已经参加 A 活动的无法参加 B 活动，那么 Service A2 肯定是要查询 Service A1 才能知道他是不是已经参加过了对吧？
至于“旧用户”这个定义，是否具体为“用户参加了 A 活动就算旧用户”，还是取决于你们的需求，我说过了，只要把需求搞明确，做法是不一样的。假设这个“旧用户”是指存储在用户服务的一个标志状态，那么此时就需要查询 Service B，而不是 Service A1 了。

另外说个题外话，微服务并不是指这种类似 RPC 调用把服务拆分开了就算的，起码有一点，用类似 Dubbo 这种 RPC 就已经就跟 Java 绑定了（虽然可以更改为 HTTP 协议来进行传输，但它终究不过是一个 RPC ）。每一个微服务可以有自己独立的技术栈用于实现，通过 REST API 来进行集成，更重要的是，在容错性上（也就是在部署层面）可以做到监控集成与故障转移。

所以个人认为微服务应该是治理性和维护性上的意义大于具体使用什么语言什么框架这种技术性问题。拆分是一门学问，过早的拆分只会引入没有必要的麻烦，应该站在业务层面还有部署层面上看待这个问题。服务发现、网关、配置、监控等等这些组件都是为了在治理性上尽量做到具有弹性。

以上这些是我个人的一些想法，无意教大家什么是对的什么是错的，而是想要让大家思考一下微服务在不同层面不同角度带给我们一些启示。

我再来帮你梳理一下什么是新用户

1 、该用户之前不存在，那么肯定要从不存在变为已存在，也就是说，区分新用户是以注册用户的这个事件为准。
2 、如果一个新用户注册了，领取了你的活动奖励，那么这个已领取的状态应是在 A 服务进行记录的，换句话来说，一个新用户应该不会领取两次奖励，再结合第 1 点以及活动推出的时间，任何创建时间大于这个活动推出时间并且该用户没有领取过奖励的就算新用户。

第一点和第二点我认为是等价的，你认为呢？

要确定这个“是否为新用户”是如何定义的，比如 3 天以内注册的都是新用户？活动推出以后注册的玩家才算是新用户？又或者是在某一个渠道条件下引入注册（创建）的用户才算是新用户？

不同的需求有不同的做法。