个人有一个观点是不要过度设计，架构是演进出来的不是设计出来的。做一些可预见的设计优化是对的，但不要想的太多做的太早，否则你会发现要么设计的东西根本用不到、要么就是不符合业务发展需要不断重构。

回到问题，我认为封装的根本是分层思想。最基本的封装就是调用一个函数了，稍微进一步调用另一个文件中的函数，再如调用另一个包中的函数，再如调用另一个服务给你提供的函数，这些我认为都是分层，函数调用可以认为是陷入另一个层再回来，操作系统调用就是 trap 到内核层再回到用户层。
分层可以让你专注你自己的业务，其他的东西由别的层负责，例如限流、风控、鉴权、日志等都是与具体业务无关的通用的功能，就可以考虑封装为独立的一层。

到了具体实现环节我认为应该首先确定好接口，接口意味着协议，至少应该是一个在未来可以扩展的协议，这对分层来说是十分重要的，也意味着未来的修改没有历史包袱。另外应该尽量做到对业务无侵入性或尽量小，否则如果与业务有很强的耦合性就应该再思考一下是不是哪里不合理了。

作为一名 2012 年注册的博客园用户和开发者，真心祝愿博客园能干成。

博客园众包平台项目的定位是「软件**任务**众包平台」，这个定位切入点非常精准，我认为是有机会做成的，但同时也面临不少风险挑战。

机会：
- 博客园把软件开发拆分成一个个任务分配到平台开发者，这一点是最大的创新，相当于把非标准化的定制需求打散成了一个个标准化的任务，这样就可以释放出巨大的供给，可以把那些没有大块时间做开发的人力吸收进来，说具体一点也许未来开发者下了班回到家花一个小时就可以完成一个任务，赚个零花钱。
- 未来一定是服务业高度发展的社会，其中包括生产性服务业和生活性服务业，而软件定制开发就属于生产性服务业。服务业规模的扩大引发服务个性化消费需求需要有定制的服务来满足。

风险和挑战：
- 需求端的不确定性：在博客园原文中描述了需求端，需求端主要是有自己开发团队的 IT 企业，众包平台不涉及软件开发项目中的需求管理、项目管理、UI 设计而只涉及写代码，这个模式很像消费行业的 OEM 模式，企业定制需求然后交给工厂生产。这种模式对软件企业来说还是一个比较新的模式，可能需要一段时间的市场探索，说白了也是成本问题，如果哪一天外包成本低于自有团队成本，这个事儿也就成了，但过程中肯定需要很长一段路要走。
- 对需求端企业的要求极高：需求端企业要有超强的项目分析拆解能力和项目管理能力，才能将需求拆分成可以独立完成的子任务以及各个子任务之间的联调最终完成整个项目。相当于企业舍弃掉了开发能力，但要大幅提高项目管理能力，有点分布式 CAP 的意思。这对企业来说恐怕很难做到。
- 项目质量如何保证：假如视这个模式为 C2B 模式，那么既然是 C 端提供产出，那么由谁来保证 C 端产出的质量？如果还是交给企业自己解决，那么对企业来说成本太高了。
个人曾经在企业有过类似经历，需要引入小游戏场景，由于没有小游戏开发团队，所以找了外包驻场，整个项目并不顺利，几度延期后最终交付效果也不是很满意，最终还是选择了组建自有团队，可想而知外包和自有团队的成本差距了。

所以我看在这个项目中关键点在于需求端的市场培养和如何降低需求端的成本，具体来说如何让需求端企业更合理的拆解任务、更稳妥的推进项目、更轻松的验收结果是关键，平台的任务很艰巨。

最后还是想说，应该用发展的眼光看问题，虽然现阶段来看风险和挑战比机会要多，但未来谁也说不准，随着社会发展很多要素会发生变化，凭借博客园的用户口碑和团队对于产品路线的坚持，我希望博客园能够干成。

@Cy86 我图里才 1.6MB/s ，你跑 50MB/s 那相当于单机跑出几万 QPS 了

我也接到短信了，话术是有几十万积分月底清零，点链接兑换，还好我这个人比较穷，几十万积分怎么可能？？
写了个脚本跑的热门电商搜索词，大部分请求都是返回空商品列表，估计商城里商品并不多，猜也就是几百个品差不多了。
https://i.imgur.com/hZxgDex.png

MVCC = trx_id + roll_pointer + undolog 版本链 + ReadView
ReadView 结构中维护了当前事务开启时的活跃事务 id 列表，判断可见性就是 5 楼说的规则，这就保证了 repeatable read 隔离级别下不会出现不可重复读问题。

至于幻读问题，按照 SQL 标准来说 repeatable read 隔离级别是会出现的，但 MySQL InnoDB 的实现中避免了幻读，主要是通过 MVCC + Gap Locks 实现的。因为幻读描述的是在一个区间内的两次查询会出现原本不存在的行、或原本存在的行消失了，Gap Locks 通过在一个区间内加锁，导致后续事务无法修改数据，从而避免了幻读的发生。

你都说高峰期接口耗时日志明显增加，建议先查后端逻辑。
有可能后端因为某种原因响应很慢，导致 Nginx worker 无法快速响应前端，直到把 worker 全都占满。
如果是这种情况的话，问题出在后端，调高负载均衡配置不解决根本问题。

@Sawyerhou topK 用小顶堆恰恰就是为了不把所有数据放进堆里吧，这样复杂度 logk ，要是用大顶堆 logn 了。
还是说我没理解你的意思，用大顶堆是有什么特殊考虑吗？

这题如果是纯算法题，那么除了外部排序加最小堆真没别的思路了。
如果是个实际工程题那就可以并发处理，每组并发线程都做 topK ，最后汇总 topK ，类似 MapReduce 。

蹲个后续看看纯算法的话有其他什么方案。

官网这篇文章确实有些晦涩，甚至文档一开始就表示如果想要搞协程，建议干脆直接用 channel 或 sync 包就完了，不用看文章内容。
可能官方文档出于严谨考虑，写的东西非常理论化，实际效果又有点反直觉，确实不好理解。
我读过几次心得主要是，文章说明了 go 在协程并发环境下可以提供的保证有哪些，也就是所谓 happens before 、synchronized before 这类保证，这种保证可以让开发者放心的写代码，因为只要符合这些保证生效的场景，就必然可以得到可预期的结果。
反之除了文章中提到的场景外，其他并发场景就不提供任何保证了，换句话说啥结果都可能冒出来。

至于为什么可能出现死循环，我想应该跟底层硬件有关了，例如 sync 包很多同步操作底层都涉及到屏障操作，就是让不同 CPU 寄存器中的数据可以在一致的前提下被读写，那么反之如果不使用任何同步原语，那也就不涉及到屏障操作，不同 CPU 可能持有的还是各自不同的副本...

@rocliu2020 是的，我刚回复里也想提来这一点来着，可能广州当地朋友感受不明显，甚至完全就是我自己的意淫。不过旅行嘛，就是从自己呆腻了的地方去到别人呆腻了的地方的过程，无论去哪只要让自己感受到了没有过的体验就很好。

我也是裸辞之后出去玩了一圈，我本身是北方人，工作生活也一直在北方，所以出去主要选择了南方城市，感受一下另一种生活，写了一篇游记算是回忆 https://www.lipijin.com/southwest-walk

成都的安逸和重庆的夜生活都给我留下了很深的印象，但让我最喜欢的还是广州。广州给我一种不疾不徐、淡定从容的感觉，就像穿城而过的珠江一样，她不像川渝地区的长江那样大开大合，反而呈现出的是安静隽永。
生活在这里的人们仿佛也有着同样的特质。在珠江边钓鱼的人中有大叔也有小伙儿，一辆小踏板外加一根鱼竿，走到哪甩到哪；广场上有打牌益智类活动，也有乐队唱跳文体类活动；拍结婚照的情侣请来了两个醒狮助阵，摆出 pose 时周围的人会鼓掌喝彩；这里仿佛每个人都自得其乐，你很精彩，我也不差。

有机会我还想去广州，如果可以的话我会考虑去广州定居。

风险应该没有，更多的是成本问题。注册运营公司的成本考虑了吗， 包括一次性成本和定期成本，也是一笔不小的数目，考虑清楚就没问题了。

GAP 了一年，之前是跟着同事+室友出去创业，公司做了八年。
业务经历过辉煌，也跌入过低谷，辉煌的时候得到了国内最大电商的投资，低谷时业务量跌落回了初创期水平。
回想从毕业开始结识了这些同事又一起出来创业，虽然结果可能不完美，但过程足够精彩，我觉得已经非常幸运了。
对我来说，创业真的是一件让人上瘾的事，有一种痛并快乐着的感觉。
最终选择离开并决定 GAP 是因为业务已经事实上宣告失败了，虽然业务还在线，但在可预见的未来肯定会逐渐衰减，势不在了。
想到这么多年一直在路上匆忙赶路，并没有停下来关注下自己，关注下家人，好像特别关注一些所谓的“正事儿”，同时又忽略了更多的事，所以我决定停一停，稍作歇息，再重新出发。

「纳指的年化平均都有 30%左右。贷款年化目前一般只有 3.x% 。」
这么算下来，简直可以抵押车房、向亲戚朋友借钱、各种小额贷全搞一遍，能贷多少贷多少，然后全仓进纳指。
你想想为什么别人不这么干呢？

不要回答！
不要回答！
不要回答！