A

上周的教训让我学乖了，时间紧迫顺着选了个简单题，小心翼翼地自己按题干写好了测试断言，除了数组其他啥结构都没用，本来想了下要不要手撸一个链表或者队列，后来想想问题规模这么明确，相当于数据范围相当固定，就不搞事情了，当然是一次提交就过了

只可惜

运行时间和内存消耗让我大跌眼镜

尤其特么内存的，以后还好意思说别人写的无良么…

仔细看了下官方题解，确实还是自己不懂数学，这玩意儿咋辅导孩子功课呢

R

这周英文的部分一直不知道咋整，因为…我真的有点开始正儿八经的练练英文，而不只是完成这个作业；如此一来，如陈老师课程中课程编辑导读中所说，语料这东西，贵精不贵多，别说陈老师课程中那个Product-Minded Engineer了，我上周临时找的Google Elite Team Project Zero都还在精读练习阶段，可是这个作业总得每周看点新东西吧，毕竟这里说到底是磨练技术的吧（这么一整，上周似乎跑题，连Review这项的要求的目的似乎也有那么点模糊，忽然考虑一段时间之后，直接share一篇来批判下这个ARTS学习方式的方方面面的…）

好在选 Share 部分的主题的时候，忽然找到了一个好东西，如下面那个tip一样，够玩儿一阵的，就是Elasticsearch的References doc

这周选的ES里面的所谓Transport这个概念

笔记

也许这是review的本意？

结构和内容复述

分三大段，概述、配置（Transport settings）和tracing（这也不知道怎么翻，它叫Transport tracer）

概述部分

概述有两段，讲的倒是都是比较有用的概念

Transport的全称，应该指得是 the transport networking layer，是用作集群内节点内部通信的，每个节点和节点之间的call都要通过这个，举了个例子，响应（外部的）的HTTP的GET的请求的时候，一个节点接收到这个请求，但是数据在另一个节点，那么这时候两个节点就用transport来通信；然后就是一个很重要的概念，Elasticsearch Java API 中那个那个被废弃的TransportClient，也是这玩意儿（看行文应该是指共用了一部分代码）

第二段讲的设计特点和思路：完全异步的，响应前没有阻塞；这种设计一是为了应对C10K problem，也就是高并发大负载了，另一个是因为ES里面搜索的时候要有拆分和合并操作（这个估计值得也是指的所需要的数据在多个节点上，可以认为是node.master=false,node.data=false这种节点干的事情？），逻辑完备，满分

配置部分

首先是强调了下，transport这玩意儿是TCP基础上的通讯（communications over TCP），所以引出了一大票配置，跟通常用TCP协议的上层应用通常都会有的一些配置，什么port host connect timeout之类的，这里不多扯了，细节直接移步原文档靠谱，但注意这里实际上涉及了服务端和客户端两类配置，比如connect timeout么，本来也是只应该发生在客户端身上，但是注意他针对主机有publish/bind两类，不带这两个前缀的，属于把这两类直接设成同一个值

一个子章节是Trnasport Profiles，提到可以通过多个不同的profile来管理在不同的interface（可以简单地理解为网卡吧）上来绑定不同的端口及一系列的其他配置参数；这里还提到一个叫default的profile，一个是如果其他的profile某些配置值没有给值，就用default了（所谓fallback）；还有一个它本身还是一个客户端配置（how this node connects 同other nodes in cluster）

这部分仔细研读还要参考另一个章节 Network settings，一方面是概念相关，另一方面，配置参数也差不多，本身有的说的也就是一回事儿（我也没仔细比对）

然后特别强调了三个概念且与之相关的配置：长生命周期的空闲连接、请求压缩、响应压缩，这哥仨占的篇幅还不少，这里也复述一下吧

Long-lived idle connections

ES需要保持节点之间的连接，即便这些连接可能很大程度上是空闲的，总之如果由于一些配置的原因，例如节点假设跨越了防火墙，那么有可能会被防火墙的一些检活配置直接断掉了这些idle的连接，这时候集群状态可能会出问题，为了省却这些麻烦吧，需要正确的配置tcp.keep_alive（优选配置，这个在上文中对后一个配置项的说明中有提到）或者transport.ping_schedule来保持这些长连接

Request compression

强调了几点，一个是transport.compress为什么缺省是false，因为压缩耗费CPU，而且这个配置值缺省是假设为local cluster这个目标来建立的，说白了就是同一个子网或者近似的网络环境，这种环境基础设施上就是个fast network，所以那意思也没必要搞压缩了云云…

另一个是transport.compress这个配置如果想和remote cluster的compression 配置区分开了，因为上面说了，这个本地的倾向于不压缩，如果remote要压缩，local不压缩咋办？就不能只设置transport.compress了，这时候需要一个其他的配置项，叫做cluster.remote.${cluster_alias}.transport.compress，而且是按per-remote cluster来配置

其实到这里正常人（如果不了解remote cluster这个概念的）应该都对remote cluster相关概念有了些兴趣，这东西确实有专文描述，看看要不下期继续这个？

Response compression

这段说的简单，就是没配置来特别控制响应时候是不是压缩，请求是压缩的，那响应就是压缩的，还特别强调了，假设请求不是压缩的（别人那里配置的transport.compress是不压缩的），那么自己这里响应回去的也是不压缩的，尽管自己的transport.compress配置了压缩，所以说白了也就是transport.compress也是个客户端配置…

另外上文在描述transport.compress配置时候提到压缩算法是 DEFLATE，DEFLATE和zip、gzip其实有必要专文辨析，这里没说，我也不多事儿去扯了

Tracing部分

这块儿比较简单——应该认为是文档写的有点糙，看起来就是个日志记录器，写Java的人对这玩意儿不陌生，不过这个看他文档说的实可以通过REST API直接设置（can be dynamically activated）；另一方面，include excluide概念上好理解，但是举的例子怎么写那个exclude规则，真是没看懂

Review 总结

• transport 是ES集群内节点用来通信的一种机制，一套不同于其对外的HTTP的RESTful风格的协议，TCP基础之上的，异步、长连接是其基本设计，要注意与这些基本设计特征相关的配置值以及与ES系统相关联的其他基础设施的配置
• Tracer么，就是查问题用的，可以动态的激活，include和exclude没看懂，但是考虑到咱们linux下面也就是grep什么的·，也不纠结了

T

tip现在看起来最简单了，因为现在认知上没歧义，容易落地…

这个其实我觉得没啥大用，算是给强迫症患者用的，不过考虑到每个人某些时候都会有点儿——就看你在乎什么了，所以看一下也值得

果然他这个设置的位置，不知道是不是我这个intellij的版本（ultimate 2020.1）的问题，实际上是在settings -> editor -> proofreading ->spelling，如下图，翻了一下没找到，实际上是search box里面敲了spelling搜索到的，我觉得我这个手段比他这个tip更像tip吧

这里竟然对于我还算有个生词，proofreading，proofread… 查字典说是校对（read … and mark any errors），proof是证明么，也好理解…

他这个Preferences，不知道是其他版本的intellij对应的settings叫preferences呢还是有个其他入口，后面领悟了再来补充吧

另外这个觉得真不是啥tip，IDEA把这项做个tip of the day有充数之嫌，搞的我这个周的T合着就背了一个单词：proofread，read and mark any errors，了，也算默写了一小遍

至于我自己后面，我觉得还是直接用alt + enter 对波浪线直接加到自定义字典了这种居多，面临的是换机器怎么同步的问题，后话了，刚才也瞜了一眼，看截图他有个所谓Project-level dictionary，这好像就是alt enter里面选择加入的额那个字典，它的存储位置缺省是在工程目录的.idea子目录里面，这下好了，.idea通常是被gitignore的，那到底用什么机制来同步到别的电脑也能用呢（真不是怪癖，我经常的一种工作形态，我讨厌电脑背来背去的）不得而知，再继续就是tip引发的血案了，没工夫玩，总之就把这个tip当作告诉我拼写检查的字典在哪里设就可以了吧

S

这周的share还是实际工作中遇到的问题诱发的，这周其实遇到很多值得仔细写一写的问题：

• servlet api为啥不提供getBody之类的方法（雅雯那个问题）
• 既然in.read(byte[] buf)也不会读出全部的，那它岂不是也是非阻塞IO了（还是雅雯那个问题）
• 短链接的BIO套路写法回忆下（依然是雅雯那个问题，难道这个礼拜我就干了最后加班那一个小时？）
• jenkins多JDK配置怎么搞（试图尝试改造服务到java 11时遇到的问题）
• 集群node应该怎么样分配（尝试分析运维用ES cpu报警时遇到的问题，这个还诱导了我找了篇本周的R的主题，估计未来几周的都有了，就跟 T 一样）

但最后决定写一写究竟应该怎么养成习惯的问题

首先呢，我决定退群，退出现在这个ARTS打卡群，因为：

• 这个群也没能帮助我坚持下来，我第二周差点就放弃了
• 我找到了一个更好的诱惑，骚尼的4K电视，这个没啥大用，但是又实际确实能对家里设施做点升级，这东西也不是买不起，就是让我们败家的更有些理由吧

其次呢，我给我家大仔也列了一个task，完成这个task，我就答应他买他想要的天文望远镜
最后呢，这周对于我主要的一个困扰就是如何激励团队（下周运维组人员补齐，就也又有这个问题）成员向着一个更好的自己去成长的问题，但这个我没啥action，因为我不知道每个人到底想要的是什么；我在这个事情上想要的其实非常简单，就是teammate越强大，我实际上就会越轻松，所以我才会不停的对大家扯这些事情，除此之外，什么共同成长之类的，其实都没那么伟大的想法

也不展开多说了，其实就是share一个view么：

要养成一个习惯，最简单的办法还是得有一个有足够诱惑力的目标，外部压力除非生死攸关，或者真的是极为丢脸，可是考虑到现如今都是社会人儿，人人脸皮都比鞋底厚，恐怕还是利诱来的划算

其实退不退群也都无所谓了，尤其是自己已经决定继续…

为了骚尼的4k电视，有ARC的HDMI接我的Sonos Beam，有真4k接我的Xbox one S 看蓝光而不用非得把投影仪拿出来，也为下一世代主机做好必要基础设施建设，有真HDR，PS上享受地平线和奎爷版的爸爸去哪儿，我勒个去，想想就美…我这个人还是挺容易动摇的，被敌人抓住了恐怕都挨不到动美人计的时候…