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

@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 天以内注册的都是新用户？活动推出以后注册的玩家才算是新用户？又或者是在某一个渠道条件下引入注册（创建）的用户才算是新用户？

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

16 年买的 MBP15，是新模具的第一批产品，我觉得最垃圾的就是 touch bar 还有键盘，其他的目前还好，小心爱护一下还是比较持久的，外接显示器+蓝牙键盘+trackpad2 。

+1 ZSBD

体力劳动和脑力劳动，后者更能磨练一个人的意志，只有心灵强大才是真的强大。

1 、前端请求服务器（通用接口），获取 Token 以及文件 URL 路径信息，此 Token 用于调用 OSS 云存储 SDK 传入，Token 一般是 Base64 编码后的一长串字符串，SDK 上传至 OSS 云服务器，OSS 云服务器负责校验 Token 以及解析 Token，并根据元信息（业务后端生成 Token 时指定的桶、文件名称）把文件放到指定的位置。这个 Token 类似 JWT 这种结构，里面包含了元信息以及签名。
2 、SDK 上传完毕后，提交表单把 URL 路径信息提交至业务服务器，业务服务器直接保存 URL 路径。
3 、读取的时候，只需要 URL 路径，后端就可以拼接域名+路径得到完整的访问路径，如果是私有的则需要加上访问 Token，那么后端只需要提供一个根据 URL 路径得到访问链接的通用接口即可，前端就可以调用这个接口批量转换解析。

将上传和解析链接独立出来，成为一个通用的接口，业务使用上就可以直接保存 URL 路径，而不必重复上传或解析的工作，前端也可以根据这两个通用的接口得到自己想要的数据。

在调用生成 Token 这个接口上面，可以自定义参数，比如使用场景、文件类型限制等等，方便与 OSS 进行集成，接口在获取这些信息以后就可以生成对应的 Token 以及准备上传文件的 URL 路径，或其他前端需要在上传阶段需要得到的信息。
如果需要区分不同的桶，则可以在保存的 URL 路径上增加特定的前缀，这样解析服务就可以知道这个 URL 路径到底是哪一个桶的，不过不推荐这样做，不同的业务应该使用各自不同范围的服务，而不是一个大统一的跨项目的通用接口。

至于为什么不在业务数据直接返回的时候直接拼接，这取决于前端的需要，其实前端可以合并请求一次性获取。另外就是如果在后端进行拼接，那么每一个接口都需要知道域名等信息，我的建议是不要把业务数据的 URL 路径当做是一个路径或者链接，而应该把它当做一种特定格式标识符，标识符是需要被二次解析的。想象一下如果返回的数据中不仅要包含 URL，还要包含文件名以及大小上传时间等，跟业务数据的耦合性就比较大。或者这一步至少通过一个过滤器来完成，通过注解（ Java ）的方式来统一处理，否则会有大量重复枯燥的代码。

个人对于国内做游戏这一块并不看好，问自己几个问题：
有什么东西是你能做的而腾讯抄不了的？
你做的游戏在同类型的市场里面有什么竞争优势？
别人凭什么来玩你的游戏，而他们真正玩的又是什么？

要对这几个问题有所思考和准备，至少支撑自己的信念以及理由不会轻易动摇。
比如玩家玩的实际上是你的 IP，你的游戏内容高度贴合原著，有粉丝基础（至少有人愿意来玩一下）。
比如游戏的世界观，文化背景，如果是原创的，那么这部分内容就是你的核心竞争力，游戏的世界观就像文学一样，可以模仿，但是无法替代。至于游戏玩法，这么多年下来就那么些套路，只是外观不一样罢了。

我目前只见过做游戏服务端的有在使用这个语言，因为可以与 erlang 集成，语法也很方便，但是招人的话就是问题了，所以那些规模比较小或者直接换皮复用的游戏用的应该比较多。

如果是 MySQL 的话，我以前测试过，在大批量数据插入情况下（数据迁移），关闭以下这些选项插入更快：
关闭自动提交模式
关闭索引
关闭外键检查

至于 INSERT 语句一次插入一条还是多条，区别在于网络 IO 耗时，在内部速度应该都是一样的，不过返回来想一下，这种合并插入语句更难以维护和编写，除非特殊情况否则不建议这么做。

详见： https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-bulk-data-loading.html