当然可以，无非慢而已，一般来说需要进行合并，设计表的时候注意用自增标识，guid 等方式预留合并需求

异地多活系统

这种高并发需要考虑下幂等性接口设计，让请求针对同一请求的 requestid 做相同返回处理，后台只执行一次

去安全组或者在防火墙封对方 ip 即可

大概一年多前就有人挖掘出了查信用分办法

是真的，真到除了本人，其他人只有 0.0000000001%的可能

很简单，a 创建一个带参数的 url，b 扫描该 url 并追加自己的 token 访问下，然后 a 就轮训结果看是否有有效 token 访问了标有某参数的 url

如果你将来数据库达到跨 2 台以上机器，你立刻会改口说很合理！
这种规定说明制定规则的人出发点有分库思路，当然业务是否能达到用的上分库则是另一个话题

我正在做的博客发布系统最近卡壳了。。。

@summerl0l 只是明着不能有

搜了下，背后的那一排插口实在是太惊艳了

@nwljy 虽然可以，但是这个功能你不会真敢用在公网吧？ im 通信一定得用一套自己的通信协议来实现数据加密的

@inktiger 是的，达到业务效果怎么着都行。我最早的交换通信就是只用 memcached 全局共享存下所有公网连接信息，然后各个服务器收到消息通过 memcached 找准服务器，然后内网用短链接精准转发消息

@shenjixiang 你用了 mq 也仅仅是对到达服务器的顺序做了个强制排序而已。
我做过类似聊天业务，回想下业务场景，一对一私聊，0.1 秒的时差就已经足够对消息排序了。即使把并发考虑到钉钉那种 5000 人大群的规模，用微秒本身去排序也没啥大问题的，因为同一微秒的消息即使乱序，也已经不会对群消息造成直接影响了（网络因素本身就已经不能让消息不是微秒级别都准确了）

大部分人对于大型系统的理解，中间件成了必不可少，完全错了，中间件只是为了解耦合和提高吞吐！
如果你的 socket 服务端可以做到精确命中目标连接所在服务器然后转发，那么 mq 这一层显然必要性就不高了，毕竟你只有 10 台机器的压力负载

@xuanbg 谁敢说 20 可以那举报他了

不允许明说的

这个首先考验的是物理 io 能力，比如我的 gps 服务器业务，变了法的优化，如果局限于单硬盘，机械硬盘物理单条数据的 sqlserver 写入速度，5400 转笔记本机械盘实测 4000 多已经是极限了。
其次看你框架优化能力，比如缓存，把 io 从硬盘转移到内存，可以立刻轻松获得 10 倍以上效果。
再看你集群能力，一台机器不行，合理的软件架构可以让 10 台并行处理，轻松扩展

当然，第三条未必真的用在第三位置，设计合理的架构，用在特别低端的机器上也可以用堆硬件的方式来达到效果。这就是云架构这一类，云服务器的虚拟硬盘 io 都是特别差的，但是这并不一定影响项目扩容