积攒许久链接，于是该用短文方式。改名 many links仿O’Reilly的Four Short Links.
1.
Kafka Streams Topology Visualizer
正如其自述“A tool helps visualizing stream topologies by generating nice looking diagrams from a kafka stream topology descriptions.”
如果你苦于向他人解释采用的kafka stream 数据处理逻辑，可以考虑该连接生成可视化图片展示，适合作为架构设计插图。
2.
The world beyond batch: Streaming 101
老文章，流式数据处理101，正如文述“A high-level tour of modern data-processing concepts.”值得一看
不过文章显然着重是对几个“时间”的理解以及流的粒度探讨：
Event time vs. processing time
Data processing patterns
Bounded data/Unbounded data — batch
Fixed windows/Time-agnostic
Filtering/Inner-joins/Windowing
3.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

使用火焰图展示结果
1、Flame Graph项目位于GitHub上：https://github.com/brendangregg/FlameGraph
2、可以用git将其clone下来：git clone https://github.com/brendangregg/FlameGraph.git
我们以perf为例，看一下flamegraph的使用方法：
1、第一步
$sudo perf record -e cpu-clock -g -p 28591
Ctrl+c结束执行后，在当前目录下会生成采样数据perf.data.
2、第二步
用perf script工具对perf.data进行解析
perf script -i perf.data &> perf.unfold
3、第三步
将perf.unfold中的符号进行折叠：
#./stackcollapse-perf.pl perf.unfold &> perf.folded
4、最后生成svg图：
./flamegraph.pl perf.folded > perf.svg

不知不觉的，一年过去，这一年，家人身体安康，幸事。然而来者不可知也。

下面是之前2-3个月积攒的文摘，清空一下，所以有些看起来可能是不够“新鲜”了。

1, Dubbo源代码分析九：优雅停机
http://manzhizhen.iteye.com/blog/2404220
这几天从dubbo-admin有机会看了一点dubbo代码，对上述shutdown方式，有了点体会。
可以说2.5.3版本 dubbo和dubbo-admin交互还是有多处bug的，比如可以对比 com.alibaba.dubbo.registry.integration.RegistryProtocol在2.5.3和2.5.8版本的实现（doChangeLocalExport/notify方法）。

3，python根据项目生成requirements.txt
查看一些python项目，很多并未采用requirements.txt方式，编译起来耗费时间，今天学到了可以用 pip freeze的方式：

python项目中必须包含一个 requirements.txt 文件，用于记录所有依赖包及其精确的版本号。以便新环境部署。
在虚拟环境中使用pip生成：
(venv) $ pip freeze >requirements.txt
这种方式配合virtualenv 才好使，否则把整个环境中的包都列出来了。
使用 pipreqs
这个工具的好处是可以通过对项目目录的扫描，自动发现使用了那些类库，自动生成依赖清单。
缺点是可能会有些偏差，需要检查并自己调整下。
# pip install pipreqs
# 使用方式也比较简单
pipreqs ./

很久没有写博客了，感觉快要生疏，今天简单写一点，记录发现的几个问题。

1，
在集群增加一个节点后，不要只看是否启动成功，一定要验证下是否加入集群
考虑到32G内存的官方推荐，很多人会选择同一物理机部署两个以上节点（>128G内存），分配两个端口。比如9300/19300.
比如集群在 10.135.30.12:9200/9300 是一个master节点，之后拷贝配置新增如下一个节点：

1
2
3
4
5

cluster.name: elasts
node.master: false
node.data: true
transport.tcp.port: 19300
discovery.zen.ping.unicast.hosts: ["10.135.30.12"]

会发现该节点启动成功，但是没有加入到elasts这个cluster里。 设置为debug级别再启动，不仔细看是发现不了问题的。

很久没有更新了，最近比较忙。
今天刚好是第33个教师节，怀念因吾逃课多次而气哭却依旧对我苦口婆心谆谆教诲到毕业的高二高三班主任。可惜花无重开日，人无再少年。当爱因斯坦霍金这些天才的头脑思考想象时间之箭逆向的时候，凡夫俗子只能哀叹滚滚长江东逝水，但将白发唱黄鸡？
所以，第一个链接附上：邓晓芒的邓晓芒：我的恩师修斋先生

1. 优雅停机
   dubbo原生是支持优雅停机的，其实也就是采用JDK的ShudownHook来实现，当然仅限kill -15 PID。这里也顺带说一下dubbo优雅停机的原理，如下所示：
   服务提供方
   · 停止时，先标记为不接收新请求，新请求过来时直接报错，让客户端重试其它机器。
   · 然后，检测线程池中的线程是否正在运行，如果有，等待所有线程执行完成，除非超时，则强制关闭。
   服务消费方
   · 停止时，不再发起新的调用请求，所有新的调用在客户端即报错。
   · 然后，检测有没有请求的响应还没有返回，等待响应返回，除非超时，则强制关闭。
   阅读全文 »

1. 阿里周洋分享了中间件技术峰会分享|双11高可用架构演进之路, 介绍了阿里第四代技术架构，将其分为了，容量规划、限流降级、依赖治理、开关预案、故障演练、流量调度。
   其实这是一系列，另外一篇中间件技术峰会分享|阿里电商架构演变之路，很简略的概括了阿里架构史，其实也是国内很多公司开发的架构史。里面将淘宝架构分为：
   淘宝从初创开始到今天，我们的技术架构总体上经历了四代：
   第一代是基于LAMP的一套结构。第二代是基于Java的应用架构。第三代是基于分布式体系，构建出一整套的分布式架构。第四代是基于IDC，不但应用能够分布，整数数据中心也能够分布。
   这里也可以看出，前三代，阿里跟随国外技术圈。本人工作过几家大公司其实也是该思路。

2. 10,000 Java performance tips over 15 years - what did I learn
   上面是油管链接，也可以去voxxed 2017, devoxx conf上面一些基于JVM语言／优化等链接还是很值得看的。

   阅读全文 »

记录一下看书收获。

1. 什么是熵

让我们先看一下维基百科对玻尔兹曼熵的来源描述和定义：

熵（Entropy），是一种测量在动力学方面不能做功的能量总数，熵的量度正是能量退化的指标。
熵亦被用于计算一个系统中的失序现象，也就是计算该系统混乱的程度。
1877年，玻尔兹曼发现单一系统中的熵跟构成热力学性质的微观状态数量相关。玻尔兹曼并假设：
S=k*lnΩ
公式中的k是玻尔兹曼常数，Ω则为该宏观状态中所包含之微观状态数量。这个被称为玻尔兹曼原理的假定是统计力学的基础。
统计力学则以构成部分的统计行为来描述热力学系统.

这就是玻尔兹曼的Entropy的来源了，而当普朗克来中国讲学时用到entropy这个词时，还没有对应名称，胡刚复教授偷懒地根据公式（dS=dQ/T），把“商”字加火旁来意译“entropy”这个字，创造了“熵”字（胡刚复与叶企孙同样是我国近代物理奠基人）。
不过上面是物理学衍生的玻尔兹曼熵，在1948年，克劳德·艾尔伍德·香农将热力学的熵引入到信息论，定义了信息熵的概念，因此它又被称为香农熵。

在信息论中，熵是接收的每条消息中包含的信息的平均量，又被称为信息熵、信源熵、平均自信息量。
这里，“消息”代表来自分布或数据流中的事件、样本或特征。

这即是熵的定义了，这里隐含的想法是，比较不可能发生的事情，当它发生了，意味着更多的信息。
所以熵也可理解为不确定性的量度[Measure of Uncertainty]，即越随机的信源的熵越大。

分享一下在学习逻辑回归时候的困惑，以便需要者节约时间。

在看西瓜书的逻辑回归这一章时，对作者引入了sigmoid函数觉得突兀，于是搜索到了知乎上的提问，为什么 LR 模型要使用 sigmoid 函数 里获赞最高的答案。
但正如马化腾先生说的，这么说，也对也不对。
看完后，上面其他回答各种理由，而匿名回答是最大熵的，并不是原因，甚至，这可以认为是一个推论或公理。试想再问为什么要熵最大化？
换言之，一个分析问题是从前一步的因，一个分析问题是从最初的因。这对数学专业可能会直接跳过这么问。

Blogs

1, 10,000 Hours With Claude Shannon: How A Genius Thinks, Works, and Lives
上个世纪，尤其是前50年，伟大的天才很多，开拓的天才屈指可数，有些是大众皆知如爱因斯坦，图灵，而知道香农就没有那么多。作者总结了香农许多习惯，试图解密为何香农会有那么多的时间创造，或者思考。
2，Makers专访Margaret Hamilton, NASA’s First Software Engineer

Meet Margaret H. Hamilton, the woman who led man to the moon. 
On July 20th, 1969, minutes before Apollo 11's scheduled touch-down, 
there was a computer error that would have changed history had it not been 
for Margaret's programming that overrode the glitch and ultimately made 
"one small step for man, and a giant leap for mankind" a reality.