另外说个题外话，微服务并不是指这种类似 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

现在的云服务器一般入口带宽都比较高，换句话来说，客户端上传速度有多快取决于客户端的带宽有多高。但是大多数业务不能只上传吧，还得下载，这就是服务器的出口带宽，价格比较昂贵。

所以现在一般都直传 OSS，然后通过 CDN 进行分发，当然也可以省略 CDN，只不过费用也是按照流量来计算的。

@aoizz 按照这个思路，很难想象你一次性要获取 10W 的用户（根据 getByIds，使用 SQL IN 语句？），优化的核心思路在于时间跟空间的平衡点，数据查找尽量使用 SQL 通过数据库来筛选数据，充分利用好数据库的索引功能，避免一次性获取大量数据，然后只使用里面的少量数据。

不过最重要的还是看数据量与看场景，是 OLTP 还是 OLAP，前者尽量保证短时间内完成操作，后者更多的是通过提前创建派生数据来提高查找速度（以空间换时间）。

在不进行预处理的情况下，你可以简单的改为并行流然后查找，users.stream().parallel().filter...，或者 users. parallelStream().filter...

祝你生日快落~，祝你生日快落~，哈皮巴斯得图友啊~，祝你生日快落~

1：如果是多终端，修改来源不止一处，比较好的方式就是使用订阅机制，相当于多个生产者和多个消费者，同步只需要同步本地不存在的数据，使用一种递增的序列标识来表示数据的前后顺序。

2：使用日志式的存储比较容易实现，即数据只是简单的追加，不涉及到修改，如果有修改或者删除的需求，也仅仅只是追加一条数据（墓碑记录），当然了，数据无止境的累加也是不现实的，因此可以异步定期的去压缩数据（合并同一条记录的修改、移除已被删除的数据），这其实就是许多数据库背后的原理，用在应用层上也是同样的道理，其目的在于减少复杂的 IO 操作（在本例中是为了减少对数据库的复杂操作），提升整体的处理效率。

不太清楚你们的应用场景具体是怎么样的，简单的说一下思路：已经发生的事情是客观存在的，就像一个个事件，我们不能改变过去，但是可以补偿过去，其结果就是如果严格按照先后顺序处理这些事件，其结果最终都是一致的。定期压缩数据也只是建立了一个快照点，这样其他客户端就可以直接从这个快照点获取整个数据，然后在基于这个快照点的版本 ID，去同步之后的事件。

最后说一下问题，多个生产者产生数据可能会遇到冲突问题，需要共识算法来达成一致，这就是典型的分布式问题（比如上面的全局序列 ID/版本号），如果要做到这一步就需要结合业务场景做取舍，取决于你的业务复杂程度。

举个例子，我们都对 git 比较熟悉吧，如果两个人基于同一个版本提交，那么当他们试图同步彼此的时候，必定有一个人需要 merge 或者 rebase，如果对同一个文件修改了，可能还需要处理冲突。为什么说它是分布式的呢？因为可以脱离服务器，在自己本地独立的进行操作，以后同步的时候只需要大家对提交记录达成共识即可。

最后，以上这些都是基于你有多个终端修改源，并且需要同步到多个终端上的假设作为前提，如果只有一个生产者，那么这些问题都不存在了。

2XX：请求成功
4XX：客户端错误
5XX：服务端错误

如果只返回 200，不方便日志的收集和监控预警，因为把错误相关的信息都放到响应体内了，如果有日志相关的收集需求，那么就意味着要去解析响应体。

见过很多前后端分离的项目，不管是成功还是失败，都一股脑返回一个包装体结构，里面大多有 3 个字段（ code，message，data ），其实这三个字段不管在成功还是失败的情况下都存在冗余。

比较推荐的做法是，HTTP 状态码仍然继续使用，该返回什么数据直接返回，也不需要一股脑全部加上一个包装体，还美其名曰为规范，在请求正常的情况下，code 和 message 是多余的字段，前端其实只需要里面的 data 。

在错误的情况下（ 4XX 和 5XX ），此时统一返回一种表达错误信息的格式才比较有意义，如果仍然返回之前的包装体，那么 data 字段也是冗余的。

@qiumaoyuan 没有分歧，我只是想回复你一下，然后分享一些关于这件事情的一些想法，前面两段内容是我的一些看法。后面两段也算是具体回复一下关于这个帖子的一些解决思路。

先不考虑是否长连接，如果你用 HTTP 来做，那么当你在发起请求之后，网络断开了，此时你是处于未知状态的。保存有可能成功，也有可能失败。

你可以在发起请求的时候创建一个唯一的 ID，这样服务器就可以支持幂等操作，你可以随意重新尝试 N 次，但是服务器只会处理一次。这样当你丢失连接以后，你可以随意再次发起一次请求，只有当你明确收到服务器的响应说这个请求已经处理完的时候，此时你再删除本地的文件。

@qiumaoyuan 规范的最终目的是服务于团队的，也就意味着想要提升整个团队的工作效率，就像代码是给人看的而不是给机器看的。进一步落地的方案可能是统一命名风格、禁用某些特性。时代在进步，同样我们使用的数据库或者其他中间件也在不断的改进和优化，但是很多方案却止步不前。开放学习和进步的团队文化是至关重要的，在我看来，现在很多的规范都已经过时了，也许在那个时候确实是有理由这样做，但是发展到现在就有点像用明朝的剑斩清朝的官。

反映出来的现象就是，由于很多人学习了这些早期项目的编码实践，后来又被其他人给继承，我不知道他们有没有仔细想过这些细节，但是科学的方法是进一步测试，得出实实在在的证据表明这些实践是否仍然有效。试图发现和总结出现这些现象的原因是另一个问题。

回到主题，对于楼主这个问题，我认为不在于 IN 本身是否好坏，而在于你的业务场景是否适合使用 IN，在 OLTP 场景，响应时间是至关重要的，同时也要保证数据的一致性和完整性，解决思路就是在时间和空间之间取得一个平衡。

对于下单来说，大多数系统需要保证操作及时响应，这也就意味着你不能进行太多耗时的操作（大部分时间花在了 IO 上），但是对于查询来讲，实时性也许就不那么强，或许可以通过异步的方式产生派生数据（即根据订单数据生成另一份数据），这一部分数据可以专门优化为方便查询的结构。当然是否采取这种方法取决于楼主业务的实际使用场景以及我方才这些假设是否成立。