@xiaoxuz

是的，看个人风格——所以手持臃肿的铁锤的人就是那么喜欢臃肿的钉子。

如果能只在自家臃肿就好了，放过那些新手，免得把 go 社区更多小白也整成臃肿的了。

另外，中了臃肿的毒的人，可能根本不知道自己中毒了。

“模式”党不要过度污染 go 了吧，隔三差五就看到 java 味道的 go，本来简简单单几行代码搞定，被你们一搞，哦豁。

问问他阿里 P 几，如果是>=P9，听他指挥，如果小于 P9
问问他这种 low p 靠谱的少、多数是跳到其他中小团队负责一些管理然后专业坑队友自己心里没点 B 数吗
别说什么 P7 专家 P8 高级专家，7/8 里真正对得起架构师、专家、高级专家这些头衔肯定是有，但是靠谱的比例非常小

尝试下 websocket rpc 如何，可以服务端主动推送之类的，比 rest 舒服多了：
[server]( https://github.com/lesismal/arpc/blob/master/examples/protocols/websocket/server/server.go)
[client]( https://github.com/lesismal/arpc/blob/master/examples/protocols/websocket/jsclient/hello.html)

看看这个吧：

18 年收益 14.5 万倍，神秘香港富豪成亚洲新首富！

　　上帝之手：神秘账户从事黄金现货的交易，在过去的 18 年里，他的收益高达 14.5 万倍。

　　美国期货商品交易委员会(CFTC)近日在审查中发现，一个开户地为香港的神秘人物，其交易账户中的资金额超过 1170 多亿美元，创造了新的历史记录，这个不知名的神秘人物成为了新的亚洲首富，甚至以实际可操控的资金量计算，他的资产远远超过了世界首富贝佐斯。

　美国期货商品交易委员会表示:目前暂不知道这名人物叫什么名字，属于哪个国籍，由于严格的交易人保密原则，仅知道这个人的交易编码。他于 2003 年在香港交易所开设账户，从事黄金现货的交易，在过去的 18 年里，他的收益高达 14.5 万倍，创造了上帝也不可能做到的交易奇迹。目前美国商品交易委员会已经向香港交易所 2 函，要求对其个人是否在交易过程中存在的违规行为进行调查，并且要求香港金融监管委员会配合转交这名交易人的开户资料。

　　美国期货商品交易委员会称如此大的资金池，即便是最低保证金的交易量，也足以对全球资本，期货，现货和黄金市场掀起惊涛骇浪，但却在过去的十几年中没有被发现。CFTC 查阅了过去 18 年来这名神秘人物的交易记录发现，他的每次交易量都一直保持在很低的水平，似乎是用“复利”的魔法在累积巨额的财富。虽然他的账户金额高达千亿美元，但过去 18 年来，他通过英国渣打银行总共提取的资金只有数千万美元。

　　美国期货业协会首席专家，纽约大学教授詹姆斯·克伦威尔表示: 我们需要知道的是，这名神秘富豪是如何做到如此高的收益率的，全球期货和现货市场并不像股票市场，可以进行人为操纵和干预，这几乎不可能。如果他是靠自己的能力做到的，那么他将比沃伦·巴菲特强万倍。

一个显示器或者 mbp 才多少钱。有些公司把办公用的什么 mbp/pc 、工学椅、显示器弄高大上一点，然后压低工资，而且这些还都是公司的固定资产，离职了公司只是付出个折旧费用。
而大部分这种提供好配置的，都压工资，单按钱算，给你配好点环境，多花万八千或者一两三万，但是一年却至少能省几万。如果公司不给配，自带设备但是别压工资都划算

所以，应该是给配 4k 的公司大部分公司别去。

另外，越高清似乎越伤眼睛。

亚马逊谷歌这些都是按量计费，容易翻车，前几个月有个帖子就说有个小公司差点因此破产

用国内厂的包带宽的这种，不走按量计费，坏处是量小浪费钱，但好处是损失可控

按量计费遇上恶意攻击，就只能依赖云厂良心了

楼主玩 python 但不是做 AI 方向，有点可惜人才了，早点全面转 go 会大大提升自己在服务端的上限

一个三层一个四层，通常：
人工排查网络故障普通问题用 ping
业务服务相关并且 ping 不能满足需求（比如某端口是否开启）的软件功能开发用 4 、7 层建连或 req/res

看你实际要做什么，比如云厂的服务端口健康检查或者自家 devops 节点服务状态检查，这本身不是 ICMP 这种三层专用协议能做到的，就需要业务层自己开发

@no1xsyzy 大部分是 IO 导致的延迟，不能简单按延迟和 CPU 数量计算

4c8t 虚拟机：
cat /proc/cpuinfo| grep "physical id" | wc -l
8

./wrk -t4 -c800 -d10s --latency --script=./echo.lua http://localhost:8080/echo
Running 10s test @ http://localhost:8080/echo
4 threads and 800 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 4.23ms 3.00ms 73.33ms 82.50%
Req/Sec 47.86k 4.49k 57.78k 73.25%
Latency Distribution
50% 3.71ms
75% 5.39ms
90% 7.38ms
99% 13.35ms
1906200 requests in 10.04s, 269.05MB read
Requests/sec: 189888.68
Transfer/sec: 26.80MB

如果按延迟计算，平均延迟 4.58ms，最多
print(1000/4.58*8)
1746.72489083

但实际跑出来是 Requests/sec: 189888.68

@byte10 高手，之前的帖子你们聊着聊着就不见了：
https://www.v2ex.com/t/755862

现在 http1.x/tls/websocket 都支持了

本想再支持下 http2.0，但是 http2.0 太渣了，只适合替代 1.x 的接口类业务，但是又不如 ws，所以我放弃 http2.0 了，等以后 http3.x 吧，那时候不再需要 tcp 做 http 载体了，不过目测 2030 年也未必能普及

周神好帖！
越读书越觉得自己会的少，学得越多越觉得自己无力。
但愿楼上随便喷周神观点的各位有朝一日都能具备真正俯视其内容的实力。

生气那是开玩笑呢，v 站 emoji 不显示 :joy: 不知道怎么破，好像是可以输入表情来着，忘记怎么搞了

再补充点吧：如果你的数据是只有几十万甚至几百万这种量级，直接内存做也可以，这点内存不值钱。比如启动时初始化，分批查出每条数据按照你需要的关键字生成一条 string，存到 trie tree 里，查询时按关键字最多到最少循环查询，大于等于 limit 数量时结束循环。如果数据需要动态更新，更新 tree 成本也很低。
甚至，就内存里按关键字弄几个排好序的，二分查找就是了，除了 go 这种，其他很多语言本身就自带这些有序的 container，没啥成本

如果数据量是持续增长的，目前的数据量，改造成本也不大，早治疗早解决。

1. #4 中描述只有几十万数据，是固定的地址数据吧？这里没有给出详细信息
2. 问的问题是 sql，#6 中说改造 es 是指什么？到底用的 sql 还是 es，我的回答里好像没说需要改造成 es 。另外，但就这个查询来讲，sql 和 es 都适用
3. 这个接口功能是地理位置推荐

综合下：数据数量几十万、地理位置推荐，那我排除是按收件人地址类的搜索，假定你的数据量数量固定为几十万。

如果是按照位置范围内远近进行推荐，mongodb 有地理位置存储和查询的支持，可以考虑数据导入到 mongo，导入时把地址的经纬度信息带上，然后再做，就简单了，而且比你用字符串可能更准确
如果不需要按位置远近这种，只需要简单优化 sql 性能，#5 几种姿势说的很明白了，并且你才几十万数据，这么点数据量改造成本太低了。我怀疑楼主要么没看我的回答要么就是懒，然后还继续问什么奇技淫巧，那老夫我现在有点生气，不想再回答了 :joy:

一，插入数据前对 detail_site 进行标准化，比如广东深圳、广东省深圳市、中国广东省深圳市之类的，省市格式统一标准化成中国-省-市，然后直接 detail_site order by，不需要函数，需要修复旧数据
二，需求降级，问问产品，能不能不 order by 这么细，就按 detail_site 字符串排序，如果可以，就不需要用函数了
三，新增整形字段作为省、市排序值，更新当前所有记录的该字段值，后续插入时带上该字段值，查询用这两个值 order by

ps：单一手段不可行的情况下，就要从不同的层次、角度考虑，穷则思变，不要局限在 sql 本身上

合同是你签的，建议多拍几个她煮着东西的时候洗澡、包括你提醒她的视频，以后万一你不在家她把房子烧了也好有个证据

简单直接的判断方法：
3 为临界值，n=3 时最多向下 n-1/n-2/n-3，即 recur 最小的参数 n 为 0 ；
每个 n 对应的值都进行记忆的前提下，每个 n 只需要调用一次 recur ；
首次调用 recur(6)，则整个过程需要对 0-6 挨个计算、记忆，所以是 7 次（不管小于 3 的参数是否记忆，当 n=3/4/5 时 n 也被缓存过、不会被重复调用，所以小于 3 的也不会被重复调用）。
可以类推首次调用大于等于 3 和小于 3 的次数

这篇文章讲得不错：
https://www.163.com/dy/article/G9LK0LIH0511FQO9.html