这种万能手适合做兼职

isee

桌子底下放点东西，比如快递的小箱子，买一整包纸抽也行

刚开始我也比较和气，什么事理解下，后来发现跟题主一样，对方根本不领情还觉得理所当然

网站：
首先要有个小目标：
认识 html
然后 css
然后 javascript
然后一个网站就建成了（^_^）

app 的话，入门难度大多了

@lixiangzaizheli 我见过我一个前端同事用他英文名做前缀， 一组图片分组^_^

@yrebom 终于说到点上了，如果是 [读多写少] ，你要做的工作就很简单了：
公网 SLB 一台，低配 ECS 多台，如果有网站附件文件再来个 OSS 和 CDN，然后你早期可能只需要一台 RDS，将来多了，修改代码实现全部修改和写入进入主库，然后那一堆 ECS 分组读取不同的从库
搞定！多少年内不用改代码，只需要业务量增长加机器就行了

@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 元？看银行卡并不是经过第三方需要手续费的样子

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