三长一短选一短啊，明显这几个孩子都不太灵啊

@neosfung 感觉自己突然傻 B 了。。。。

@neosfung 这个文章我看了，关于分治法的一个疑问，一个大文件取出现概率前 100 的数，就是吧一个大文件分成 N 份以后取每个文件的前 100 ，再归并排序，但是为什么整个文件的前 100 的数一定在这 N 份文件的 TOP100 里面？？会不会出现一个数是每个文件的 TOP101 ，但是整个文件里面是 TOP100 内的？

买了一台低配的 1 核 1G1M ，搭了梯子和 NEXUS ，内存不够了。。。。

方案是有的，就是极其损耗性能：
使用存储过程游标查询，从头遍历表，直到查到纪录为止。

最好是只遍历一次，依据数据，建立索引表，链式纪录，指向前一条纪录和后一条纪录 id ，索引表如果数据量不大可以完全缓存在内存里，这样直接命中主键，效率会很高

@firefox12 对，你说的没错。全异步队列的吞吐确实可以很高，但是大并发下消息的可靠性可能会有问题，再者既然您这边有红包生成，必然有预算管理，一个系统不可能凭空无限制生成钱出来。然而有预算的扣减必然有扣减的持久化，最后才到微信支付的交易（划账）的过程，一个预算的扣减，一个预算消费纪录的持久化这 2 个 IO 操作，必然是整个系统的瓶颈所在，所以个人感觉抛开瓶颈，测试的无非是 MQ 的性能和大并发下的内存管理问题，对于一个“系统”来说，可能差距还是有点的

简单的看了一下说明，没有太细致的研究，但是貌似缺少了持久化的步骤，纯内存操作确实可以很快，但是对于涉及到交易，支付的系统，如何保证整个流程的完整性和数据的可靠性?

@neoblackcap 已查证，你说的基本是对的

@neoblackcap 为啥不能在 dell 的机架服务器上装 mac 的服务器操作系统，具体没有用过不清楚，只是有不表示一定要用，据说 apple 自己的所有服务都用的自己的操作系统。

@sylecn apple 不出服务器，但是他有服务器版本的操作系统

@argon33 是的，哦，我的资料里是上海，很久以前设置，一直没有改

@argon33 北京

@hst001 用 ios 的理由就是流氓少。。。安卓自启动，全家桶坑爹

可以排查下线路的问题。。也有可能是网线有问题，国内大部分的支持自动翻转，国外的不支持。。。中间有老路由 OK 的情况，可能是老路由支持，自动翻转以后新路由可以识别

@noli
本来我是不想回的，因为这种脱离生产的为辩论而去做辩论，没有特别的意义。但是看到你这么酸的。。。。。

我从主贴上看到您是驳斥这种 Json Envelope ，你希望通过只处理 http 头来解决问题。。。但是后续又提出“ HTTP 错误码是为工作在 HTTP 层的各路非业务设备看的 ”，那我的理解就是关于资源有无，应该是业务层，而非 HTTP 层的。。所以真心不知道你是什么观点。
至于你说的：“ curl -i 就可以看到是哪个服务器发出来的响应了。 ”
我觉得没问题，能解决问题，但是，如果不用这些方法，只是通过日志直接能判断服务的问题，这样的效率不是更高，只是为了遵循某个规范，而搭进去排查运维、开发的人力和时间成本毫无意义。

至于你提的 2 大厂。。。只是代表了一种设计思想（错误码和 json 同时使用），但是并非强制标准抑或其他。


国内几大厂以及主推微服务架构的 Netflix ，则推行的则是 HTTP 状态只负责链路层，业务错误由另外结构体处理。
从 spring-cloud-feign 上来看，目前的方案是：非 200 的错误的处理方案是统一的 errorDecode ，也就是非 200 由处理链路层的方法去统一管理。

所以说不管方案是不是纯血的 Restful ，贴近生产，符合实际，能提高劳动效率的方案才有意义吧。

@noli
我说的负载的问题是，如果你用 nginx 的时候，如果 ng 配置有误，会返回 404 。

如果是服务调用方的失误（写错接口，复数多 s 少 s 很正常）或者服务提供方修改了接口定义（实际遇到过，手误在写接口名时，敲 ctrl+s 未成功，直接写出一个 s 而不自知，单元测试不通过 http 调用，未测出来）出现 404 是没有办法和业务状态的 404 所区分，特别是服务更新或者出现问题，很难定位是部署出现问题还是业务本身问题，运维和开发如果分离的情况更复杂。

如果使用 json envelop 的话，实际上就是自定义错误体系，区分了 http 状态和业务状态。

宽泛的说错误码和异常的作用可以等同，但是上文特指 Exception ，请勿偷换概念

个人觉得， Restful 只是一个参考而已。。实际应用中还有很多问题，前后端调用只是一部分，涉及到微服务调用上情况会更复杂，举个 404 异常例子：
前后端分离情况：足够描述资源找不到的问题，对用户来说不管什么问题，都是没找到资源而已。
微服务架构：完全不够，造成 404 的问题，有可能是没有部署这个接口，也可能是负载均衡有问题，也可能是真的没这个资源，还有可能是参数组合有问题（也可以用 400 描述，但是 400 情况同样，具体不到哪个参数有问题）。
所以说， restful 只是一个风格而已，未必要完全一样，在 RPC 里很容易解决的问题，在 http 上可能有很多问题，不管是 ice ， thrift ， dubbo 可以定义大量的异常，同时不需要修改数据结构，但是到 http/restful ，没有异常这个概念，是需要定义量的错误码，还是复用原有的 http status ，我个人觉得还是自定义统一的错误体系会更好

西数红盘 4t X4
准备再搭一套 He8 X4 的

现在的题目已经不为检验技术能力工作了，纯粹为了考验而考验，脱离了实际运用。。。