@yrebom 数据库总体来讲，也是我一直以来的困惑，量上来之后必然有一个瓶颈点，目前能想到的是：iops，并发连接数，文件大小三个方面
看准确瓶颈点在哪，就足够交付，瓶颈点不需要现在就去突破或者消除，但是一定是预期时间内不能遇到的。

方向一：可以考虑分布式的，例如阿里云的 DRDS，由于时间成本和价格成本问题我一直没去实际测试，等我后面时间宽裕了我会去试试

方向二：直接在软件架构上设计扩容方案，这个方向在传统架构里经常看到，例如我那种 [写多读少] 可以程序哈希分库或者做个中间路由库调度写入不同数据库。这种方案是将瓶颈点尽量往远期推迟。直到将来的路由数据库压力饱满才需要再次改造
方向三：根据业务特征，例如 V2EX 的帖子这种 [读多写少] 的业务特征可以只是用一主多从解决，这里我举得例子就是早期不需要消除瓶颈点，而是瓶颈点一时半会到不了，显然 V 站新建帖子数量一时半会不会达到每秒几千（数据库每秒写入几千），足够为下一步升级留够时间

举个例子，我做个 socket 服务端，(GPS 应用 TCP 并发长连接)，确实做到了单机 3 万很稳定，加 2 万也能正常运行，但是后来再也不看重单机指标了，换成了弹性云架构。因为
1，业务增长容易，单机性能难提高
2，重启一次，各种连接恢复周期长达 20 分钟以上，期间重建链接满载消耗 cpu
3，单点故障会导致一个崩溃级 bug 毁掉整个业务
4，压力太集中，早期 memcached 雪崩时候，数据库读炸了一次

总之，一个长久的业务，需要把架构做成不改代码只增加机器数量就能解决业务增长问题，这才是云架构发展起来的意义，云的单机性能都是远远低于物理机的，云时代不应当看重单机性能指标

单机做不到的，及时做到了，其他瓶颈也就出来挡着你了，你现在应该考虑的是，slb，一堆一模一样的 ecs 挂到 slb 后端，数据库用一个 RDS 还不见的够用

印象中百度云是第一个提供时序数据库的云

不能退确实是基于某些因素考虑，可是不能转让确实很霸道

在互联网上，居然有这么多眼睛盯着网民的一言一行

腾讯云的登录最近改了好几次，又一次不知道什么 bug，我一不小心唤起 qq 登录居然把我最近聊天的一个人的 qq 给登录到腾讯云了

同样想知道绑定了那些，在上家公司申请过几个，都不知道自己绑在那些帐号上了，现在自己申请都费劲
腾讯系似乎除了腾讯云真没有人工客服

小黄车的强制充值金额让人吐血。
前阵子去杭州交了押金骑了，然后用完了发现因为欠着 1 元不能提现，然后充值发现最低 5 元，另找了找还有个小额充值最低 3 元，冲了 3 元之后才能提出来押金 199。
不是差那 2 元余额，而是我离开杭州确实用不到小黄车
虽然现实当中确实经常有零头忽略不计的例子，但我觉得小黄车这像是故意行为，能做 3 元不能做 1 元？看银行卡并不是经过第三方需要手续费的样子

外包归外包，也是有各种门槛的，这种人渣能越过门槛，说明存在管理漏洞

建议楼主换个思路，大量遍历他的邮件图片像素，通过污染黑客数据方式换取被命中的概率

果然黑产，邮件像素识别打开的方式居然被这样使用了

异地登录可能是 ip 库不准的问题，我用手机网络访问我的服务器就偶尔有这个情况，把那个误报的 ip 对比不同数据源确实得到不同的结果

看了好几遍愣是没看懂题目，在关键字“如果”那里之前，感觉就是十个蛇形来回弯曲。
关键字“如果”那里实在没看懂

没猜错的话，你这也是写的 gps 终端设备通信 socket 服务端
这种协议自定的内容，你得自己写代码，你顶多找到 socket 的接受发送半成品

比我慢多了，我是页面还没关就接到了电话

我觉得这位大佬仅仅是没发威。能面进阿里，起码得有点技术功底，只不过缺少需求去表现出来技术实力而已

做过私活都知道各种坑，好活一般不会外包的

小厂无规矩
我体验过这家，空载情况下，断了一天啥都没任何通知，只等着我去问