1.
NIPS不更名，我就撤资：赞助商加入联合抗议行列
https://www.jiqizhixin.com/articles/2018-11-02-12
不过后来还是改名字了 NeurIPS
以后看文章要找对地方啊。
2.
GitHub Incident Analysis Shows How to Improve Service Reliability
https://www.infoq.com/news/2018/11/github-incident-analysis
GitHub服务中断24小时11分钟事故分析报告
https://mp.weixin.qq.com/s/fFv1ASElHsVNEPPkP53qAQ
了解下：
GitHub 拥有多个 MySQL 集群，大小从几百 GB 到 5TB 不等，每个集群最多有几十个只读副本来存储非 Git 元数据，因此我们的应用程序可以提供拉取请求和问题管理、身份验证管理、后台处理协调等原始 Git 对象存储之外的其他功能。应用程序不同部分的数据通过功能分片存储在各种集群中。
为了大规模提高性能，应用程序将数据直接写入每个集群的主数据库，但在绝大多数情况下将读取请求委派给副本服务器。我们使用 Orchestrator 来管理 MySQL 集群拓扑和处理自动故障转移。Orchestrator 以 Raft 的共识算法为基础，可以实现应用程序无法支持的拓扑，因此必须十分小心让 Orchestrator 配置与应用程序的期望保持一致。
3.
Java应用性能调优之调优准备
http://www.rowkey.me/blog/2018/10/31/profile-ready/
基本涵盖常见注意点，可以保存文章随时查阅。
总结简单记住几个命令：
|
|
4.
1年将30PB数据迁移到Spark，eBay的经验有何可借鉴之处？
http://www.infoq.com/cn/articles/ebay-30pb-spark
文章似乎404了，不过infoq上站内搜索还是可以搜索到，似乎没讲啥，但可以了解下这件事：
eBay 使用 Teradata 已经有二十年的历史，这个数仓系统中积累了 60PB 数据和上万张核心表，他们支撑着 eBay 最核心的商务逻辑和站点功能。从今年开始，eBay 开始将这个庞大的数仓由 Teradata 向 Spark 做迁移，使用 eBay 自己开发的工具，迁移过程中 90% 的工作都可以由自动化完成。与此同时，研究人员通过优化 Spark 框架，节省了一半的内存。
…
eBay 第一期迁移的数仓就有 30PB 之大，包括 5000 张的目标表、20000 张的临时表和 50000 个作业。经过估算，如果是手动迁移，大概需要 1000 个人月，相当于 50 个数据工程师，专职做迁移也需要两年， 这是非常大的开销。所以 必须做自动化迁移。
…
尽管团队已经预先为大型数据仓库迁移可能会面临的问题设计了应对方案，但在真正启动数据仓库迁移后，依然遇到了很多挑战。俞育才给我们举了几个例子：
1)“大规模数据下的正确性验证。我们可能会直观地认为，双跑验证就可以了。尽管理论上是这样，实际情况往往会复杂很多。首先，数据源是不断变化的，目标表依赖的任何一张源表数据发生了变化，结果就会不一致。所以，双跑的时间点很重要。其次，即使数据源固定，跑多次结果未必是一致的。比如，在 Spark 中有个 UDF，可以给返回每一行加上个 ID。但实际上，这并不是一个幂等操作，因为 Shuffle 不保证每次返回行的顺序，所以每次编上 ID 都是不一样的。对于这样的列，我们就不能做比较。类似这样的问题还有很多，都需要特别注意。
2)非标准流程作业的迁移。在老的 Teradata 数仓中，大约有 10-15% 的作业并不是按照标准流程创建的，这些作业无法做自动化迁移，或者自动化的成本很高。所以，在初期做规划的时候，要尽可能收集到足够的信息，把他们都标识出来，然后尽早地联系相应的开发，或者修改作业，或者做手动迁移。
3)开源软件的企业级特性的支持。一些企业级软件提供的易用功能，现在的 Spark、Hadoop 还没有提供。比如：监控和调试信息还不是很完善，排错起来不是那么方便；对分析师来说，他们也缺乏一个好的 IDE 帮助他们做开发。这并不全是 Spark 的问题，我们自己开发了很多外围的组件来帮助改善这些问题。
5.
一文看懂Pinterest如何构建时间序列数据库系统Goku
http://www.infoq.com/cn/articles/how-pinterest-build-goku
虽然 OpenTSDB 在功能上运行良好，但其性能随着 Pinterest 的增长而降低，导致运营开销（例如严重的 GC 问题和 HBase 经常崩溃）。为了解决这个问题，Pinterest 开发了自己的内部时间序列数据库——Goku，其中包含用 C ++ 编写的 OpenTSDB 兼容 API，以支持高效的数据提取和成本昂贵的时间序列查询。
时间序列数据
Goku 遵循 OpenTSDB 的时间序列数据模型。时间序列由一个键和一系列时间数字数据点组成。key = metric name + 一组标记键值对
时间序列查询
除了开始时间和结束时间之外，每个查询都由以下部分或全部组成：度量标准名称、过滤器、聚合器、降采样器、速率选项。
…
Goku 解决了 OpenTSDB 中的许多限制，包括：
1）不必要的扫描：Goku 用倒排索引引擎取代了 OpenTSDB 的低效扫描。
2）数据大小：OpenTSDB 中的数据点是 20 字节。Pinterest 采用 Gorilla 压缩来实现 12 倍压缩。
3）单机聚合：OpenTSDB 将数据读取到一个服务器上并进行聚合，而 Goku 的新查询引擎是将计算迁移到更接近存储层的位置，该存储层在叶节点上进行并行处理，然后在根节点上聚合部分结果。
4）序列化：OpenTSDB 使用 JSON，当有太多数据点要返回时，JSON 会很慢；Goku 使用 thrift 二进制代替。
…
存储引擎
Goku 在内存存储引擎中使用了 Facebook Gorilla 来存储过去 24 小时内的最新数据。
分片和路由
我们使用两层分片策略。首先，我们对度量名称进行散列，以确定某一时间序列属于哪个分片组。我们在度量名称 + 标记键值集上进行散列，以确定时间序列在所在组中的哪个分片。此策略可确保数据在分片之间保持平衡。同时，由于每个查询仅进入一个组，因此扇出保持较低水平，以减少网络开销和尾部延迟。另外，我们可以独立地扩展每个分片组。
…
查询引擎
a)倒排索引
b)聚合
从存储引擎检索数据后，开始进行聚合和构建最终结果的步骤。
Pinterest 最初尝试了 OpenTSDB 的内置查询引擎。结果发现，由于所有原始数据都需要在网络上运行，性能会严重下降，而且这些短期对象也会导致很多 GC。
因此，Pinterest 在 Goku 中复制了 OpenTSDB 的聚合层，并尽可能地早地进行计算，以尽量减少线上的数据。下一步：
a)基于磁盘的长期数据存储
Goku 最终将支持超过一天时间数据的查询。对于像一年这样的时长查询，Pinterest 将不会过分强调一秒钟内发生的事情，而是关注整体趋势。因此，Pinterest 将进行降采样和压缩，把以小时计的 bucket 合并为更长期的时长，从而减小数据量并提高查询性能。
b)复制
目前，Pinterest 有两个 goku 集群进行双行写入。此设置提高了可用性：当一个集群中存在问题时，可以轻松地将流量切换到另一个集群。但是，由于这两个集群是独立的，因此很难确保数据的一致性。例如，如果写入一个集群成功而另一个未成功时，则数据写入失败，数据由此变得不一致。另一个缺点是故障转移总是在集群层面发生。为此，Pinterest 正在开发基于日志的集群内复制，以支持主从分片。这将提高读取可用性，保持数据一致性，并支持分片级的故障转移。
6.
Alternative code styles
https://swalladge.id.au/archives/2018/10/15/alternative-code-styles/
算是搞笑文章吧，标准之外的选择，大开眼界了，特别是 斐波那契缩进的风格：
知名如
PEP8 for Python
Linux kernel coding style for C
Airbnb JavaScript Style Guide
Ok, so there are also plenty of infoadm ation, history, tools, etc. for popular styles. Enough on them. Let’s look at some lesser known alternatives!
Bournegol
Let’s begin with the most (im)famous alternate code styles! Bournegol is the C coding style used by Steven Bourne in the sh source code. It makes C look more like Algol, which some would argue has a nicer syntax. Below is a snippet from main.c (source):
DISCLAIMER: use the styles that follow at your own risk.
Poetry
Code can be an art form. While function is generally put before form in code, it doesn’t hurt to break the trend and produce source code that is in itself beautiful.
Fibonacci indentation
Indentation has always been a hot topic. Tabs or spaces? Two, four, or even eight spaces? Let’s add a new option! Welcome to Fibonacci indentation.
7.
关于Kafka broker IO的讨论，huxihx写的，非常不错，建议可以收藏看一看
http://www.cnblogs.com/huxi2b/p/9860192.html
Apache Kafka是大量使用磁盘和页缓存(page cache)的，特别是对page cache的应用被视为是Kafka实现高吞吐量的重要因素之一。实际场景中用户调整page cache的手段并不太多，更多的还是通过管理好broker端的IO来间接影响page cache从而实现高吞吐量。我们今天就来讨论一下broker端的各种IO操作。
…
开始之前，还是简单介绍一下page cache：page cache是内核使用的最主要的磁盘缓存(disk cache)之一——实际上Linux中还有其他类型的磁盘缓存，如dentry cache、inode cache等。通常情况下Linux内核在读写磁盘时都会访问page cache。当用户进程打算读取磁盘上文件的数据时，内核会首先查看待读取数据所在的page是否在page cache中，如果存在自然命中page cache，直接返回数据即可，避免了物理磁盘读操作；反之内核会向page cache添加一个新的page并发起物理磁盘读操作将数据从磁盘读取到新加page中，之后再返回给用户进程。Linux内核总是会将系统中所有的空闲内存全部当做page cache来用，而page cache中的所有page数据将一直保存在page cache中直到内核根据特定的算法替换掉它们中的某些page——一个比较朴素的算法就是LRU。同样地，在写入page数据到磁盘之前，内核也会检查对应的page是否在page cache中，如果不存在则添加新page并将待写入数据填充到该page中，此时真正的磁盘写还尚未开始，通常都是隔几秒之后才真正写入到底层块设备上——即这是一个延迟写入操作。理论上来说，在这几秒之内的间隔中，用户进程甚至还允许修改这些待写入的数据——当然对于Kafka而言，它的写入操作本质上是append-only的，故没有这样的使用场景。
8.
Linux Kernel 4.9 中的 BBR 算法与之前的 TCP 拥塞控制相比有什么优势？
https://www.zhihu.com/question/53559433/answer/519062524?group_id=1039303887626481665
BBR是基于什么的拥塞控制？根据论文，是基于拥塞的拥塞控制（Congestion-based Congestion Control），但是看起来感觉不好理解。根据我的理解，我更倾向于称它为 基于带宽延迟的拥塞控制（BDP-based Congestion Control）。因为，BBR总是在测量最小RTT（10s内），最大Bandwidth（10 Round Trips），并且尽量控制输出到网络的数据包（in-flight）靠近 BDP（without buffer），这样既能保证带宽利用率，又能避免Bufferbloat问题。
9.
Kafka副本管理—— 为何去掉replica.lag.max.messages参数
https://www.cnblogs.com/huxi2b/p/5903354.html
今天查看Kafka 0.10.0的官方文档，发现了这样一句话：Configuration parameter replica.lag.max.messages was removed. Partition leaders will no longer consider the number of lagging messages when deciding which replicas are in sync. 即replica.lag.max.messages参数被正式地移除了，现在topic每个分区的leader副本都不再使用这个参数作为判断follower副本同步状态的依据。看到之后顿觉十分好奇于是抽出半天时间仔细研究了一下，终于弄明白了移除该参数的原因，特此记录一下。
首先我们来看一下这个参数本来的含义： If a replica falls more than this many messages behind the leader, the leader will remove the follower from ISR and treat it as dead. 即如果某个副本落后leader副本的消息数超过了这个值，那么leader副本就会把该follower副本从ISR中移除
为什么取消这个参数，改用：replica.lag.time.max.ms
简单来说，根据这个参数，当producer发送速度假设超快，那么容易不断地被踢出ISR然后重新加回ISR，造成了与leader不同步、再同步、又不同步、再次同步的情况发生，超慢时，又未必能察觉到。
9.
Stuff The Internet Says On Scalability For October 19th, 2018
http://highscalability.com/blog/2018/10/19/stuff-the-internet-says-on-scalability-for-october-19th-2018.html
dweis: I’m an actual author of Protocol Buffers :) I think Sandy’s analysis would benefit from considering why Protocol Buffers behave the way they do rather than outright attacking the design because it doesn’t appear to make sense from a PL-centric perspective. As with all software systems, there are a number of competing constraints that have been weighed that have led to compromises.
atombender: I don’t think GraphQL is over-hyped at all. Maybe it’s flawed, but the design is absolutely on the right traack. GraphQL completely changes how you work with APIs in a front end.Ted Kaminski: The present state of asynchronous I/O on Linux is a giant, flaming garbage fire. A big part of the reason concurrency and parallelism are so conflated is that we get many purely synchronous API calls from the operating system (not just Linux), and to get around this inherent lack of concurrency in API design, we must resort to the parallelism of threads.
Dan Houser: The polishing, rewrites, and reedits Rockstar does are immense. “We were working 100-hour weeks” several times in 2018, Dan says. The finished game includes 300,000 animations, 500,000 lines of dialogue, and many more lines of code. Even for each RDR2 trailer and TV commercial, “we probably made 70 versions, but the editors may make several hundred. Sam and I will both make both make lots of suggestions, as will other members of the team.”@andy_pavlo: Transactions are hard. Distributed transactions are harder. Distributed transactions over the WAN are final boss hardness. I’m all for new DBMSs but people should tread carefully.
10.
Arthas使用指南
https://segmentfault.com/a/1190000014618329
11.
FEX 技术周刊 - 2018/11/05
http://fex.baidu.com/blog/2018/11/fex-weekly-05/
富文本编辑器的技术演进之路
https://mp.weixin.qq.com/s?__biz=MzU0Nzk1MTg5OA==&mid=2247484137&;idx=1&sn=8dc25f8de7d359549520c9f198721408
浏览器提供了两个原生特性：contenteditable、document.execCommand()，contenteditable 特性，可以指定某一容器变成可编辑器区域，即用户可以在容器内直接输入内容，或者删减内容。execCommand API，可以对选中的某一段结构体，执行一个命令，譬如赋予黑体格式。基于以上，可以做出最简单的富文本编辑器。原来富文本编辑器是这么简单？当然不止如此简单！另附：[译]为数字优先新闻编辑室开发文本编辑器.
Atag - Web Components 最佳实践
http://taobaofed.org/blog/2018/10/31/a-tag/
过去一段时间，我一直在使用 Web Components 构建淘宝小程序的 基础组件 Atag。这篇文章的目的，是希望总结在 Atag 开发阶段中使用 Web Components 的经验，避免大家踩坑。另附：October 2018: A Big Month for Web Components.
蚂蚁金服移动开发平台mPaaS
https://juejin.im/post/5bd81cf2f265da0ab674096c
Android 拆分项目的方案