网络系统组织怎么用

作为一个javaer，我以前写过很多关于Linux的文章。但经过多年的观察，发现其实对于大部分人，有些东西压根就用不着。用的最多的，就是到线上排查个问题而已，这让人很是苦恼。那么，我们就将范围再缩小一下。 Linux生产环境上，最常用的一套“Sed“技巧 Linux生产环境上，最常用的一套“AWK“技巧 Linux生产环境上，最常用的一套“vim“技巧 Linux命令好像还真不少，根本原因就是软件多，也有像ag这样的命令想替代grep,但大多数命令古老而坚挺。不是因为这些软件设计的有多好，原因是一些软件最开始入驻了系统，时间久了，就变成了一种约定，这种习惯改变代价太大，就像把所有键盘的L和F换一下一样。 这片文章假定你已经了解大多数Linux命令，并了解操作系统的基本元素。如果你现在了解的命令还不足10个，下面的内容就不用看了。除了最基本的东西，本文列出一些对你的面试最常见的最能加分的地方，有些组合可能是你没见过的技巧。但本文仅仅是给出一个大致的轮廓和印象，为以后的专题性考察点作一个序。 本文中出现的所有命令，应该熟记并熟练使用。 几种比较典型的Linux系统 首先对目前的Linux版本有个大体的印象，大体分Desktop版和Server版，已经是百花齐放。 Ubuntu 最常见的Linux个人发行版，一位有情怀的南非富豪，有了钱你也可以这么做 CentOS 最常用Linux服务器发新版，RHEL的开放版本，因版权而生的轮子 Arch 滚动升级，海量二进制包，社区活跃，个人最爱 Gentoo 安装软件需要从源码开始编译，稳定，但用起来会很痛 LFS 从零构建Linux，跟着做一遍，Linux每根毛都看的清清楚楚 Kali 专做渗透用的，代表了发行版的一个发展路径，就是领域 首先要了解的概念 KISS Keep it Simple and Stupid，据说是哲学 一切皆文件 通常是文件的东西叫文件，进程、磁盘等也被抽象成了文件，比较离谱的管道、设备、socket等，也是文件。 这是Linux最重要的组织方式。 管道 | 分隔，前面命令的输出作为后面命令的输入，可以串联多个 重定向 < 将文件做为命令的输入 将命令的输出输出到文件 将命令的输出追加到文件 SHELL 首先确认你的shell，一般最常用的是bash，也有不少用csh，zsh等的，通过echo $SHELL可以看到当前用户的shell，对应的配置文件也要相应改变。 比如.zshrc,.bashrc 四大元素 进入linux，我们首先关注的是四个元素： 内存，cpu，存储，网络。 Linux提供了足够的命令，让你窥探它的每个角落。 接下来的命令都是些最常用的，不管精通不精通，想不起来要打屁股。 CPU 使用top查看cpu的load，使用shift+p按照cpu排序。 需要了解wa，us等都是什么意思 使用uptime查看系统启动时间和load，load是什么意思呢？ 什么算是系统过载？ 这是个高频问题，别怪我没告诉你 ps命令勃大茎深，除了查进程号外，你还需要知道R、S、D、T、Z、<、N状态位的含义 top和ps很多功能是相通的，比如watch "ps -mo %cpu,%mem,pid,ppid,command ax" 相当于top的进程列表； top -n 1 -bc 和ps -ef的结果相似。 有生就有死，可以用kill杀死进程。 对java来说，需要关注kill -9、kill -15、kill -3的含义，kill的信号太多了，可以用kill -l查看，搞懂大多数信号大有裨益。 如果暂时不想死，可以通过&符号在后台执行，比如tail -f a.log &。 jobs命令可以查看当前后台的列表，想恢复的话，使用fg回到幕前。 这都是终端作业，当你把term关了你的后台命令也会跟着消失，所以想让你的程序继续执行的话， 需要nohup命令，此命令需要牢记 mpstat 显示了系统中 CPU 的各种统计信 了解cpu亲和性 内存 free -m 命令，了解free、used、cached、swap各项的含义 cat /proc/meminfo 查看更详细的内存信息 细心的同学可能注意到，CPU和内存的信息，通过top等不同的命令显示的数值是一样的。 slabtop 用来显示内核缓存占用情况，比如遍历大量文件造成缓存目录项。 曾在生产环境中遇到因执行find /造成dentry_cache耗尽服务器内存。 vmstat 命令是我最喜欢也最常用的命令之一，可以以最快的速度了解系统的运行状况。 每个参数的意义都要搞懂。 swapon、swapoff 开启，关闭交换空间 sar 又一统计类轮子，一般用作采样工具 存储 使用df -h查看系统磁盘使用概况 lsblk 列出块设备信息 du 查看目录或者文件大小 网络 rsync 强大的同步工具，可以增量哦 netstat 查看Linux中网络系统状态信息，各种 ss 它能够显示更多更详细的有关TCP和连接状态的信息，而且比netstat更快速更高效。 curl、wget 模拟请求工具、下载工具。 如wget -r http://site 将下载整个站点 ab Apache服务器的性能测试工具 ifstat 统计网络接口流量状态 nslookup 查询域名DNS信息的工具，在内网根据ip查询域名是爽爆了 nc 网络工具中的瑞士军刀，不会用真是太可惜了 arp 可以显示和修改IP到MAC转换表 traceroute 显示数据包到主机间的路径，俗称几跳，跳的越少越快 tcpdump 不多说了，去下载wireshark了 wall 向当前所有打开的终端上输出信息。 使用who命令发现女神正在终端上，可以求爱 网络方面推荐安装体验一下kaliLinux，上面的工具会让你high到极点。 如何组织起来 linux的命令很有意思，除了各种stat来监控状态，也有各种trace来进行深入的跟踪，也有各种top来统计资源消耗者，也有各种ls来查看系统硬件如lsblk、lsusb、lscpi。基本上跟着你的感觉走，就能找到相应的工具，因为约定是系统中最强大的导向。 Linux有个比较另类的目录/proc，承载了每个命令的蹂躏。像sysctl命令，就是修改的/proc/sys目录下的映射项。不信看看find /proc/sys -type f | wc -l和sysctl -a| wc -l的结果是不是很像？ /proc文件系统是一个伪文件系统，它只存在内存当中，而不占用外存空间。只不过以文件系统的方式为访问系统内核数据的操作提供接口。系统的所有状态都逃不过它的火眼金睛。例如: cat /proc/vmstat 看一下，是不是和vmstat命令的输出很像? cat /proc/meminfo 是不是最全的内存信息 cat /proc/slabinfo 这不就是slabtop的信息么 cat /proc/devices 已经加载对设备们 cat /proc/loadavg load avg原来就躺在这里啊 cat /proc/stat 所有的CPU活动信息 ls /proc/$pid/fd 静静地躺着lsof的结果 一般排查问题的方法 一般排查问题也是围绕着内存cpu等几个元素去排查。下图是一张大体的排查故障或者性能问题的过程，看图，不多说。 应用场景举例 下面举例从具体应用场景来说明各种命令的组合应用，此类场景数不胜数，需要个人积累。但强烈建议将sed和awk练的熟练一些。 怎么查看某个Java进程里面占用CPU最高的一个线程具体信息？ 获取进程中占用CPU最高的线程，计为n。 使用top top -H -p pid，肉眼观察之 使用ps ps -mo spid,lwp,stime,time,%cpu -p pid 将线程号转化成十六进制printf 0x%x n 使用jstack找到相应进程，打印线程后的100行信息 jstack -l pid| grep spid -A 100 统计每种网络状态的数量 netstat -ant | awk '{print $6}' | sort | uniq -c | sort -n -k 1 -r 首先使用netstat查看列表，使用’awk’截取第六列，使用uniq进行统计，并对统计结果排序。当然，也可以这样。 netstat -ant | awk '{arr[$6]++}END{for(i in arr){print arr[i]" "i }}' | sort -n -k 1 -r 这和“分析apache日志，给出当日访问ip的降序列表”是一样的问题。 怎么查看哪个进程在用swap 首先要了解/proc/$pid/smaps里有我们所需要的各种信息，其中Swap字段即是我们所需要的。只要循环遍历一下即可。 for i in `cd /proc;ls |grep "^[0-9]"|awk ' $0 >100'` ;do awk '/Swap:/{a=a+$2}END{print '"$i"',a/1024"M"}' /proc/$i/smaps ;done |sort -k2nr End 软件领域有两种人才，一种是工程型的，一种是研究型的。在Linux领域里，相对于搞内核研究的来说，搞命令行的就属于工程型。工程型也有他自己的苦衷，比如，背诵命令就挺痛苦的，一般来说不太推荐背诵，第一覆盖的面不广，第二记的快忘的也快，浪费脑细胞。牛逼的记法就是用，用时间来冲淡烟云，见微知著，并体验其中的喜悦。爱她并天天抱她上床，真爱才成。 原创：小姐姐味道。

在开始谈我对架构本质的理解之前，先谈谈对今天技术沙龙主题的个人见解，千万级规模的网站感觉数量级是非常大的，对这个数量级我们战略上 要重 视 它 ， 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级？现在很流行的优步(Uber)，从媒体公布的信息看，它每天接单量平均在百万左右， 假如每天有10个小时的服务时间，平均QPS只有30左右。对于一个后台服务器，单机的平均QPS可以到达800-1000，单独看写的业务量很简单 。为什么我们又不能说轻视它？第一，我们看它的数据存储，每天一百万的话，一年数据量的规模是多少？其次，刚才说的订单量，每一个订单要推送给附近的司机、司机要并发抢单，后面业务场景的访问量往往是前者的上百倍，轻松就超过上亿级别了。 今天我想从架构的本质谈起之后，希望大家理解在做一些建构设计的时候，它的出发点以及它解决的问题是什么。 架构，刚开始的解释是我从知乎上看到的。什么是架构？有人讲， 说架构并不是一 个很 悬 乎的 东西 ， 实际 上就是一个架子 ， 放一些 业务 和算法，跟我们的生活中的晾衣架很像。更抽象一点，说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻，强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力？我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一，你必须要有抽象的能力，抽象的能力最基本就是去重，去重在整个架构中体现在方方面面，从定义一个函数，到定义一个类，到提供的一个服务，以及模板，背后都是要去重提高可复用率。 第二， 分类能力。做软件需要做对象的解耦，要定义对象的属性和方法，做分布式系统的时候要做服务的拆分和模块化，要定义服务的接口和规范。 第三， 算法（性能），它的价值体现在提升系统的性能，所有性能的提升，最终都会落到CPU，内存，IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子，在分布式系统我们会做 MySQL分 库 分表，我们要从不同的库和表中读取数据，这样的抽象最直观就是使用模板，因为绝大多数SQL语义是相同的，除了路由到哪个库哪个表，如果不使用Proxy中间件，模板就是性价比最高的方法。 第二看一下加速网络的CDN，它是做速度方面的性能提升，刚才我们也提到从CPU、内存、IO、网络四个方面来考虑，CDN本质上一个是做网络智能调度优化，另一个是多级缓存优化。 第三个看一下服务化，刚才已经提到了，各个大网站转型过程中一定会做服务化，其实它就是做抽象和做服务的拆分。第四个看一下消息队列，本质上还是做分类，只不过不是两个边际清晰的类，而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构，到一定量级的系统整个架构都会变成三层，客户端包括WEB、安卓和IOS，这里就不说了。接着还都会有一个接口层， 有三个主要作用： 第一个作用，要做 安全隔离，因为前端节点都是直接和用户交互，需要防范各种恶意攻击； 第二个还充当着一个 流量控制的作用，大家知道，在2014年春节的时候，微信红包，每分钟8亿多次的请求，其实真正到它后台的请求量，只有十万左右的数量级（这里的数据可能不准），剩余的流量在接口层就被挡住了； 第三，我们看对 PC 端和移 动 端的需求不一样的，所以我们可以进行拆分。接口层之后是后台，可以看到微博后台有三大块： 一个是 平台服 务， 第二， 搜索， 第三， 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门，做的就是 数据存储和读 取，对搜索来说做的是 数据的 检 索，对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说，第一代架构，基本上能支撑到用户到 百万 级别，到第二代架构基本能支撑到 千万 级别都没什么问题，当业务规模到 亿级别时，需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构，有几个地方是非常难的，首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的，同时线上业务又不能停， 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我，说他在内部推行服务化的时候，把一个模块服务化做完了，其他部门就是不接。我建议在做服务化的时候，首先更多是偏向业务的梳理，同时要找准一个很好的切入点，既有架构和服务化上的提升，业务方也要有收益，比如提升性能或者降低维护成本同时升级过程要平滑，建议开始从原子化服务切入，比如基础的用户服务， 基础的短消息服务，基础的推送服务。 第二，就是可 以做无状 态 服 务，后面会详细讲，还有数据量大了后需要做数据Sharding，后面会将。 第三代 架构 要解决的 问题，就是用户量和业务趋于稳步增加（相对爆发期的指数级增长），更多考虑技术框架的稳定性， 提升系统整体的性能，降低成本，还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战，PV是在10亿级别，QPS在百万，数据量在千亿级别。我们可用性，就是SLA要求4个9，接口响应最多不能超过150毫秒，线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢？那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务，每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样，就是数据量，bigger and bigger，用户体验是faster and faster，业务是more and more。互联网业务更多是产品体验驱动， 技 术 在 产 品 体验上最有效的贡献 ， 就是你的性能 越来越好 。 每次降低加载一个页面的时间，都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度，横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分，第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分，会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下， 接口层有feed、用户关系、通讯接口；服务层，SOA里有基层服务、原子服务和组合服务，在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务，组合服务由几个原子服务和自己的业务逻辑构建而成 ，资源层负责海量数据的存储（后面例子会详细讲）。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题，由众多的技术组件共同构建而成 。在接口层，微博使用JERSY框架，帮助你做参数的解析，参数的验证，序列化和反序列化；资源层，主要是缓存、DB相关的各类组件，比如Cache组件和对象库组件。监 控平台和服 务 治理 ， 完成系统服务的像素级监控，对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个，首先是系统架构三个利器： 一个， 我 们 RPC 服 务组 件 （这里不讲了）， 第二个，我们 消息中 间 件 。消息中间件起的作用：可以把两个模块之间的交互异步化，其次可以把不均匀请求流量输出为匀速的输出流量，所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理，它是 代码级灰度发布以及 保障系统降级的利器。 第二个 ， 无状态 ， 接口 层 最重要的就是无状 态。我们在电商网站购物，在这个过程中很多情况下是有状态的，比如我浏览了哪些商品，为什么大家又常说接口层是无状态的，其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物，选了几件商品，到了哪一步，接口无状态后，状态要么放在缓存中，要么放在数据库中， 其 实 它并不是没有状 态 ， 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个， 数据 层 比服 务层 更需要 设计，这是一条非常重要的经验。对于服务层来说，可以拿PHP写，明天你可以拿JAVA来写，但是如果你的数据结构开始设计不合理，将来数据结构的改变会花费你数倍的代价，老的数据格式向新的数据格式迁移会让你痛不欲生，既有工作量上的，又有数据迁移跨越的时间周期，有一些甚至需要半年以上。 第四，物理结构与逻辑结构的映射，上一张图看到两个维度切成十二个区间，每个区间代表一个技术领域，这个可以看做我们的逻辑结构。另外，不论后台还是应用层的开发团队，一般都会分几个垂直的业务组加上一个基础技术架构组，这就是从物理组织架构到逻辑的技术架构的完美的映射，精细化团队分工，有利于提高沟通协作的效率 。 第五， www .sanhao.com 的访问过程，我们这个架构图里没有涉及到的，举个例子，比如当你在浏览器输入www.sanhao网址的时候，这个请求在接口层之前发生了什么？首先会查看你本机DNS以及DNS服务，查找域名对应的IP地址，然后发送HTTP请求过去。这个请求首先会到前端的VIP地址（公网服务IP地址），VIP之后还要经过负载均衡器（Nginx服务器），之后才到你的应用接口层。在接口层之前发生了这么多事，可能有用户报一个问题的时候，你通过在接口层查日志根本发现不了问题，原因就是问题可能发生在到达接口层之前了。 第六，我们说分布式系统，它最终的瓶颈会落在哪里呢？前端时间有一个网友跟我讨论的时候，说他们的系统遇到了一个瓶颈， 查遍了CPU，内存，网络，存储，都没有问题。我说你再查一遍，因为最终你不论用上千台服务器还是上万台服务器，最终系统出瓶颈的一定会落在某一台机（可能是叶子节点也可能是核心的节点），一定落在CPU、内存、存储和网络上，最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候，经常很少做业务分析，技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例，像前三页占了97%，在做缓存设计的时候，我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 ， 越细致越好 。举了一个例子，大家都会用电商，电商在双十一会做全国范围内的活动，他们做设计的时候也会考虑场景的，一个就是购物车，我曾经跟相关开发讨论过，购物车是在双十一之前用户的访问量非常大，就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了，但是他会频繁的浏览购物车。针对这个场景，活动之前重点设计优化购物车的写场景， 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢？最右边的是Feed，就是微博所有关注的人，他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展，除了跟时间序相关的微博还有非时间序的微博，就是会有广告的要求，增加一些广告，还有粉丝头条，就是拿钱买的，热门微博，都会插在其中。分发控制，就是说和一些推荐相关的，我推荐一些相关的好友的微博，我推荐一些你可能没有读过的微博，我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博，实际会起多个并行的程序来读取，最后同步做统一的聚合。这里稍微分享一下， 从SNS社交领域来看，国内现在做的比较好的三个信息流： 微博 是 基于弱关系的媒体信息流 ； 朋友圈是基于 强 关系的信息流 ； 另外一个做的比 较 好的就是今日 头 条 ， 它并不是基于关系来构建信息流 ， 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合，体现在很多很多的产品之中，除了SNS，电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页，它的信息流基本由几部分组成：第一，打广告的；第二个，做一些推荐，热门的商品，其次，才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 ， 但是到后期会 发现 ， 你的 这 个流 如何做控制分发 ， 非常复杂， 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析，那么技术上怎么解决高并发，高性能的问题？微博访问量很大的时候，底层存储是用MySQL数据库，当然也会有其他的。对于查询请求量大的时候，大家知道一定有缓存，可以复用可重用的计算结果。可以看到，发一条微博，我有很多粉丝，他们都会来看我发的内容，所以 微博是最适合使用 缓 存 的系统，微博的读写比例基本在几十比一。微博使用了 双 层缓 存，上面是L1，每个L1上都是一组（包含4-6台机器），左边的框相当于一个机房，右边又是一个机房。在这个系统中L1缓存所起的作用是什么？ 首先，L1 缓 存增加整个系 统 的 QPS， 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景，只有一篇博文，但是它的访问量无限增长，其实我们不需要影响L2缓存，因为它的内容存储的量小，但它就是访问量大。这种场景下，你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景，就是L2级缓存发生作用，比如我有一千万个用户，去访问的是一百万个用户的微博 ，这个时候，他不只是说你的吞吐量和访问带宽，就是你要缓存的博文的内容也很多了，这个时候你要考虑缓存的容量， 第二 级缓 存更多的是从容量上来 规划，保证请求以较小的比例 穿透到 后端的 数据 库 中 ，根据你的用户模型你可以估出来，到底有百分之多少的请求不能穿透到DB， 评估这个容量之后，才能更好的评估DB需要多少库，需要承担多大的访问的压力。另外，我们看双机房的话，左边一个，右边一个。 两个机房是互 为 主 备 ， 或者互 为热备 。如果两个用户在不同地域，他们访问两个不同机房的时候，假设用户从IDC1过来，因为就近原理，他会访问L1，没有的话才会跑到Master，当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问，也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ，两个机房都有全量的用户数据，同时在线提供服务，但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢？CDN是典型的多级缓存。CDN在国内各个地区做了很多节点，比如在杭州市部署一个节点时，在机房里肯定不止一台机器，那么对于一个地区来说，只有几台服务器到源站回源，其他节点都到这几台服务器回源即可，这么看CDN至少也有两级。Local Cache+ 分布式 缓 存，这也是常见的一种策略。有一种场景，分布式缓存并不适用， 比如 单 点 资 源 的爆发性峰值流量，这个时候使用Local Cache + 分布式缓存，Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量，长尾的流量仍然访问分布式缓存，这样的Hybrid缓存架构通过复用众多的应用服务器节点，降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构，微博的博文主要存在MySQL中。首先来看内容表，这个比较简单，每条内容一个索引，每天建一张表，其次看索引表，一共建了两级索引。首先想象一下用户场景，大部分用户刷微博的时候，看的是他关注所有人的微博，然后按时间来排序。仔细分析发现在这个场景下， 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户，取他们的前条微博ID，然后聚合排序。我们在做哈希（分库分表）的时候，同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的，今天的热点新闻，明天就没热度了，数据的冷热非常明显，这种场景就需要按照时间维度做分表，首先冷热数据做了分离（可以对冷热数据采用不同的存储方案来降低成本），其次， 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分，那么这个用户所有数据都在一张表里，这张表就是无限增长的，时间长了查询会越来越慢。二级索引，是我们里面一个比较特殊的场景，就是我要快速找到这个人所要发布的某一时段的微博时，通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统，当系统到千万级以后的时候，越来越庞杂，所解决的问题更偏向稳定性，性能和监控。刚才说用户只要有一个请求过来，你可以依赖你的服务RPC1、RPC2，你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点，就是说一个请求从用户过来之后，在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候，这些日志落在不同的机器上，你也不知道问题到底出在哪儿，各个服务之间互相隔离，互相之间没有建立关联。所以导致排查问题基本没有任何手段，就是出了问题没法儿解决。 我们要解决的问题，我们刚才说日志互相隔离，我们就要把它建立联系。建立联系我们就有一个请求ID，然后结合RPC框架， 服务治理功能。假设请求从客户端过来，其中包含一个ID 101，到服务A时仍然带有ID 101，然后调用RPC1的时候也会标识这是101 ，所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个，你做的时候，你不能说每个地方都加，对业务系统来说需要一个框架来完成这个工作， 这 个框架要 对业务 系 统 是最低侵入原 则 ， 用 JAVA 的 话 就可以用 AOP，要做到零侵入的原则，就是对所有相关的中间件打点，从接口层组件（HTTP Client、HTTP Server）至到服务层组件（RPC Client、RPC Server），还有数据访问中间件的，这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志？服务化以后，每个服务可以用不同的开发语言， 考虑多种开发语言的兼容性 ， 内部定 义标 准化的日志 是唯一且有效的办法。最后，如何构建基于GPS导航的路况监控？我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题， 如果 单一用 户发现问题 后 ， 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么，但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控，每辆车有GPS定位，我想看北京哪儿拥堵的时候，怎么做？ 第一个 ， 你肯定要知道每个 车 在什么位置，它走到哪儿了。其实可以说每个车上只要有一个标识，加上每一次流动的信息，就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警，我们怎么能了解道路的流量状况和负载，并及时报警。我们要定义这条街道多宽多高，单位时间可以通行多少辆车，这就是道路的容量。有了道路容量，再有道路的实时流量，我们就可以基于实习路况做预警？ 对应于 分布式系 统 的话如何构建？ 第一 ， 你要 定义 每个服 务节 点它的 SLA A 是多少 ？SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义，相当于定义系统的容量。 第二个 ， 统计 线 上 动态 的流量，你要知道服务的平均QPS、最低QPS和最大QPS，有了流量和容量，就可以对系统做全面的监控和报警。 刚才讲的是理论，实际情况肯定比这个复杂。微博在春节的时候做许多活动，必须保障系统稳定，理论上你只要定义容量和流量就可以。但实际远远不行，为什么？有技术的因素，有人为的因素，因为不同的开发定义的流量和容量指标有主观性，很难全局量化标准，所以真正流量来了以后，你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施：第一，最简单的就是有降 级 的 预 案，流量超过系统容量后，先把哪些功能砍掉，需要有明确的优先级 。第二个， 线上全链路压测，就是把现在的流量放大到我们平常流量的五倍甚至十倍（比如下线一半的服务器，缩容而不是扩容），看看系统瓶颈最先发生在哪里。我们之前有一些例子，推测系统数据库会先出现瓶颈，但是实测发现是前端的程序先遇到瓶颈。第三，搭建在线 Docker 集群 ， 所有业务共享备用的 Docker集群资源，这样可以极大的避免每个业务都预留资源，但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升，这里以Java语言为例，首先， 一定要 理解 JAVA；第二步，JAVA完了以后，一定要 理 解 JVM；其次，还要 理解 操作系统；再次还是要了解一下 Design Pattern，这将告诉你怎么把过去的经验抽象沉淀供将来借鉴；还要学习 TCP/IP、 分布式系 统、数据结构和算法。

看透了就知道，从虎口里夺食，简直就是找死。######回复 @徐同乐 : 不高超算项目领导怎么赚钱？？这就是虎口夺食######怎么能说从虎口夺食呢，计算是自愿的，你开着电脑还是开着电脑，像公司上班的，反正用的不是自己家的电，无非把CPU的计算资源出租了而已，总比挖比特比现实吧？挖比特币说的在好听，不还是帮国外组织破解密码么？######ls的一句 "看透了就知道" 也是很吊. 那怎么保密么? 科研的机密数据都到用户的电脑了 你这个有点像以前哪本书介绍的p2p网络. ######所谓科研数据只是一个比方，毕竟现在X86的程序开发还是比那些超算的专用程序好写吧，企业也可以利用这个平台啊，现在那些大公司，比如QQ 360我就不信他不利用里电脑干点啥。毕竟免费的计算资源，不用白不用！######这个想法（以及很多你闻所未闻的方案）已经被很多人考虑过了，远早于 bitcoin 出现。而且有小规模的实验。 从经济性来说，这个方案很难有足够的经济动力。也就是说，如果给你的报酬超过你的电费比如 10%，那么其成本会远高于直接建超算了。 比如超算可以建在电费和气温都特别低的地方。现在的 bitcoin 矿场很多建在冰岛，常年低温，地热发电。 国内的找 2 角电费的地方，当地电富裕，电这东西存不下又输不出来，所以特便宜。 再有，民用电子设备往往不是为 24x7 持续工作设计的，长时间工作会导致损坏，坏一张显卡你挖一年都不够成本。 所以主流还是靠玩家的个人兴趣，在中国再加上办公室的免费电。我跑 SETI @Home 可能超过十年了，各种其它分布式计算也零星跑过。 不求回报，单纯因为个人爱好科学而已。 PS: bitcoin 的密码学运算基本是随机的，不能帮 FBI 破解密码。######@kchr 不过吧GFW的计算资源用在科学计算上我觉得更有意义哈哈！######回复 @徐同乐 : 那你可以动手开发这个系统，然后说服别人来用了。######回复 @kchr : yao######回复 @徐同乐 : 一天 7 厘钱，你要吗？######不管是科学计算 还是类似SETI @Home 这样的项目当他的研究成果改变世界的时候，而你参与其中，那么你就是那个改变世界的人，不是么？######比特币这类货币很重要的一个目的就是摆脱各国央行,这样做了不还是央行(zf)控制了吗######不得不说，想法很好。但是。。。你把zf想的太高大上了。等什么时候zf网站都从asp换到。net再说把。###### 实际上很早就有分布式计算项目，而且是全球的。是公益的。http://www.equn.com/wiki/%E6%96%B0%E6%89%8B%E6%8C%87%E5%8D%97:%E4%BB%80%E4%B9%88%E6%98%AF%E5%88%86%E5%B8%83%E5%BC%8F%E8%AE%A1%E7%AE%97 其实大型运算主要不能用一般的分布式，因为计算是串行运算，只有并行才能分布式。 ######我知道这个######几年前见过一个寻找最大素数的网格系统，每个人都可以参与，如果你的客服端成功找到了下一个最大素数就能获得一笔奖金。不知现在还有木有######很好的想法。问题你不是人民而是公民……………………我同学笑话我的话###### Seti@Home

你好，这里有208份资料，详情请参考：https://github.com/ty4z2008/Qix/blob/master/ds.md 《Reconfigurable Distributed Storage for Dynamic Networks》介绍:这是一篇介绍在动态网络里面实现分布式系统重构的paper.论文的作者(导师)是MIT读博的时候是做分布式系统的研究的,现在在NUS带学生,不仅仅是分布式系统,还有无线网络.如果感兴趣可以去他的主页了解. 《Distributed porgramming liboratory》介绍:分布式编程实验室,他们发表的很多的paper,其中不仅仅是学术研究,还有一些工业界应用的论文. 《MIT Theory of Distributed Systems》介绍:麻省理工的分布式系统理论主页,作者南希·林奇在2002年证明了CAP理论,并且著《分布式算法》一书. 《Notes on Distributed Systems for Young Bloods》介绍:分布式系统搭建初期的一些建议 《Principles of Distributed Computing》介绍:分布式计算原理课程 《Google's Globally-Distributed Database》介绍:Google全球分布式数据介绍,中文版 《The Architecture Of Algolia’s Distributed Search Network》介绍:Algolia的分布式搜索网络的体系架构介绍 《Build up a High Availability Distributed Key-Value Store》介绍:构建高可用分布式Key-Value存储系统 《Distributed Search Engine with Nanomsg and Bond》介绍:Nanomsg和Bond的分布式搜索引擎 《Distributed Processing With MongoDB And Mongothon》介绍:使用MongoDB和Mongothon进行分布式处理 《Salt: Combining ACID and BASE in a Distributed Database》介绍:分布式数据库中把ACID与BASE结合使用. 《Makes it easy to understand Paxos for Distributed Systems》介绍:理解的Paxos的分布式系统,参考阅读:关于Paxos的历史 《There is No Now Problems with simultaneity in distributed systems》介绍:There is No Now Problems with simultaneity in distributed systems 《Distributed Systems》介绍:伦敦大学学院分布式系统课程课件. 《Distributed systems for fun and profit》介绍:分布式系统电子书籍. 《Distributed Systems Spring 2015》介绍:卡内基梅隆大学春季分布式课程主页 《Distributed Systems: Concepts and Design (5th Edition)》介绍: 电子书,分布式系统概念与设计(第五版) 《走向分布式》介绍:这是一位台湾网友 ccshih 的文字，短短的篇幅介绍了分布式系统的若干要点。pdf 《Introduction to Distributed Systems Spring 2013》介绍:清华大学分布式系统课程主页,里面的schedule栏目有很多宝贵的资源 《Distributed systems》介绍:免费的在线分布式系统书籍 《Some good resources for learning about distributed computing》介绍:Quora上面的一篇关于学习分布式计算的资源. 《Spanner: Google’s Globally-Distributed Database》介绍:这个是第一个全球意义上的分布式数据库，也是Google的作品。其中介绍了很多一致性方面的设计考虑，为了简单的逻辑设计，还采用了原子钟，同样在分布式系统方面具有很强的借鉴意义. 《The Chubby lock service for loosely-coupled distributed systems》介绍:Google的统面向松散耦合的分布式系统的锁服务,这篇论文详细介绍了Google的分布式锁实现机制Chubby。Chubby是一个基于文件实现的分布式锁，Google的Bigtable、Mapreduce和Spanner服务都是在这个基础上构建的，所以Chubby实际上是Google分布式事务的基础，具有非常高的参考价值。另外，著名的zookeeper就是基于Chubby的开源实现.推荐The google stack,Youtube:The Chubby lock service for loosely-coupled distributed systems 《Sinfonia: a new paradigm for building scalable distributed systems》介绍:这篇论文是SOSP2007的Best Paper，阐述了一种构建分布式文件系统的范式方法，个人感觉非常有用。淘宝在构建TFS、OceanBase和Tair这些系统时都充分参考了这篇论文. 《Data-Intensive Text Processing with MapReduce》介绍:Ebook:Data-Intensive Text Processing with MapReduce. 《Design and Implementation of a Query Processor for a Trusted Distributed Data Base Management System》介绍:Design and Implementation of a Query Processor for a Trusted Distributed Data Base Management System. 《Distributed Query Processing》介绍:分布式查询入门. 《Distributed Systems and the End of the API》介绍:分布式系统和api总结. 《Distributed Query Reading》介绍:分布式系统阅读论文，此外还推荐github上面的一个论文列表The Distributed Reader。 《Replication, atomicity and order in distributed systems》介绍:Replication, atomicity and order in distributed systems 《MIT course:Distributed Systems》介绍:2015年MIT分布式系统课程主页，这次用Golang作为授课语言。6.824 Distributed Systems课程主页 《Distributed systems for fun and profit》介绍:免费分布式系统电子书。 《Ori：A Secure Distributed File System》介绍:斯坦福开源的分布式文件系统。 《Availability in Globally Distributed Storage Systems》介绍:Google论文：设计一个高可用的全球分布式存储系统。 《Calvin: Fast Distributed Transactions For Partitioned Database Systems》介绍:对于分区数据库的分布式事务处理。 《Distributed Systems Building Block: Flake Ids》介绍:Distributed Systems Building Block: Flake Ids. 《Introduction to Distributed System Design》介绍:Google Code University课程，如何设计一个分布式系统。 《Sheepdog: Distributed Storage System for KVM》介绍:KVM的分布式存储系统. 《Readings in Distributed Systems Systems》介绍:分布式系统课程列表,包括数据库、算法等. 《Tera》介绍:来自百度的分布式表格系统. 《Distributed systems: for fun and profit》介绍:分布式系统的在线电子书. 《Distributed Systems Reading List》介绍:分布式系统资料,此外还推荐Various articles about distributed systems. 《Designs, Lessons and Advice from Building Large Distributed Systems》介绍:Designs, Lessons and Advice from Building Large Distributed Systems. 《Testing a Distributed System》介绍:Testing a distributed system can be trying even under the best of circumstances. 《The Google File System》介绍: 基于普通服务器构建超大规模文件系统的典型案例，主要面向大文件和批处理系统， 设计简单而实用。 GFS是google的重要基础设施， 大数据的基石， 也是Hadoop HDFS的参考对象。 主要技术特点包括： 假设硬件故障是常态（容错能力强）， 64MB大块， 单Master设计，Lease/链式复制， 支持追加写不支持随机写. 《Bigtable: A Distributed Storage System for Structured Data》介绍:支持PB数据量级的多维非关系型大表， 在google内部应用广泛，大数据的奠基作品之一 ， Hbase就是参考BigTable设计。 Bigtable的主要技术特点包括： 基于GFS实现数据高可靠， 使用非原地更新技术（LSM树）实现数据修改， 通过range分区并实现自动伸缩等.中文版 《PacificA: Replication in Log-Based Distributed Storage Systems》介绍:面向log-based存储的强一致的主从复制协议， 具有较强实用性。 这篇文章系统地讲述了主从复制系统应该考虑的问题， 能加深对主从强一致复制的理解程度。 技术特点： 支持强一致主从复制协议， 允许多种存储实现， 分布式的故障检测/Lease/集群成员管理方法. 《Object Storage on CRAQ, High-throughput chain replication for read-mostly workloads》介绍:分布式存储论文:支持强一直的链式复制方法， 支持从多个副本读取数据,实现code. 《Finding a needle in Haystack: Facebook’s photo storage》介绍:Facebook分布式Blob存储,主要用于存储图片. 主要技术特色:小文件合并成大文件,小文件元数据放在内存因此读写只需一次IO. 《Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency》介绍: 微软的分布式存储平台, 除了支持类S3对象存储，还支持表格、队列等数据模型. 主要技术特点：采用Stream/Partition两层设计（类似BigTable）;写错（写满）就封存Extent,使得副本字节一致, 简化了选主和恢复操作; 将S3对象存储、表格、队列、块设备等融入到统一的底层存储架构中. 《Paxos Made Live – An Engineering Perspective》介绍:从工程实现角度说明了Paxo在chubby系统的应用， 是理解Paxo协议及其应用场景的必备论文。 主要技术特点： paxo协议， replicated log， multi-paxo.参考阅读:关于Paxos的历史 《Dynamo: Amazon’s Highly Available Key-Value Store》介绍:Amazon设计的高可用的kv系统,主要技术特点：综和运用一致性哈希,vector clock,最终一致性构建一个高可用的kv系统， 可应用于amazon购物车场景.新内容来自分布式存储必读论文 《Efficient Replica Maintenance for Distributed Storage Systems》介绍:分布式存储系统中的副本存储问题. 《PADS: A Policy Architecture for Distributed Storage Systems》介绍:分布式存储系统架构. 《The Chirp Distributed Filesystem》介绍:开源分布式文件系统Chirp,对于想深入研究的开发者可以阅读文章的相关Papers. 《Time, Clocks, and the Ordering of Events in a Distributed System》介绍:经典论文分布式时钟顺序的实现原理. 《Making reliable distributed systems in the presence of sodware errors》介绍:面向软件错误构建可靠的分布式系统,中文笔记. 《MapReduce: Simplified Data Processing on Large Clusters》介绍:MapReduce:超大集群的简单数据处理. 《Distributed Computer Systems Engineering》介绍:麻省理工的分布式计算课程主页,里面的ppt和阅读列表很多干货. 《The Styx Architecture for Distributed Systems》介绍:分布式系统Styx的架构剖析. 《What are some good resources for learning about distributed computing? Why?》介绍:Quora上面的一个问答:有哪些关于分布式计算学习的好资源. 《RebornDB: The Next Generation Distributed Key-Value Store》介绍:下一代分布式k-v存储数据库. 《Operating System Concepts Ninth Edition》介绍:分布式系统归根结底还是需要操作系统的知识,这是耶鲁大学的操作系统概念书籍首页,里面有提供了第8版的在线电子版和最新的学习操作系统指南,学习分布式最好先学习操作系统. 《The Log: What every software engineer should know about real-time data's unifying abstraction》介绍:分布式系统Log剖析,非常的详细与精彩. 中文翻译 | 中文版笔记. 《Operating Systems Study Guide》介绍:分布式系统基础之操作系统学习指南. 《分布式系统领域经典论文翻译集》介绍:分布式系统领域经典论文翻译集. 《Maintaining performance in distributed systems》介绍:分布式系统性能维护. 《Computer Science from the Bottom Up》介绍:计算机科学，自底向上,小到机器码,大到操作系统内部体系架构,学习操作系统的另一个在线好材料. 《Operating Systems: Three Easy Pieces》介绍:<操作系统:三部曲>在线电子书,虚拟、并发、持续. 《Database Systems: reading list》介绍:数据库系统经典论文阅读列,此外推送github上面的db reading. 《Unix System Administration》介绍:Unix System Administration ebook. 《The Amoeba Distributed Operating System》介绍:分布式系统经典论文. 《Principles of Computer Systems》介绍:计算机系统概念，以分布式为主.此外推荐Introduction to Operating Systems笔记 《Person page of EMİN GÜN SİRER》介绍:推荐康奈尔大学的教授EMİN GÜN SİRER的主页,他的研究项目有分布式,数据存储。例如HyperDex数据库就是他的其中一个项目之一. 《Scalable, Secure, and Highly Available Distributed File Access》介绍:来自卡内基梅隆如何构建可扩展的、安全、高可用性的分布式文件系统,其他papers. 《Distributed (Deep) Machine Learning Common》介绍:分布式机器学习常用库. 《The Datacenter as a Computer》介绍:介绍了如何构建仓储式数据中心,尤其是对于现在的云计算,分布式学习来说很有帮助.本书是Synthesis Lectures on Computer Architecture系列的书籍之一,这套丛书还有 《The Memory System》,《Automatic Parallelization》,《Computer Architecture Techniques for Power Efficiency》,《Performance Analysis and Tuning for General Purpose Graphics Processing Units》,《Introduction to Reconfigurable Supercomputing》,Memory Systems Cache, DRAM, Disk 等 《helsinki:Distributed Systems Course slider》介绍:来自芬兰赫尔辛基的分布式系统课程课件:什么是分布式,复制,一致性,容错,同步,通信. 《TiDB is a distributed SQL database》介绍:分布式数据库TiDB,Golang开发. 《S897: Large-Scale Systems》介绍:课程资料:大规模系统. 《Large-scale L-BFGS using MapReduce》介绍:使用MapReduce进行大规模分布式集群环境下并行L-BFGS. 《Twitter是如何构建高性能分布式日志的》介绍:Twitter是如何构建高性能分布式日志的. 《Distributed Systems: When Limping Hardware Is Worse Than Dead Hardware》介绍:在分布式系统中某个组件彻底死了影响很小，但半死不活（网络/磁盘），对整个系统却是毁灭性的. 《Tera - 高性能、可伸缩的结构化数据库》介绍:来自百度的分布式数据库. 《SequoiaDB is a distributed document-oriented NoSQL Database》介绍:SequoiaDB分布式文档数据库开源. 《Readings in distributed systems》介绍:这个网址里收集了一堆各TOP大学分布式相关的课程. 《Paxos vs Raft》介绍:这个网站是Raft算法的作者为教授Paxos和Raft算法做的，其中有两个视频链接，分别讲上述两个算法.参考阅读:关于Paxos的历史 《A Scalable Content-Addressable Network》介绍:A Scalable Content-Addressable Network. 《500 Lines or Less》介绍:这个项目其实是一本书（ The Architecture of Open Source Applications）的源代码附录，是一堆大牛合写的. 《MIT 6.824 Distributed System》介绍:这只是一个课程主页，没有上课的视频，但是并不影响你跟着它上课：每一周读两篇课程指定的论文，读完之后看lecture-notes里对该论文内容的讨论，回答里面的问题来加深理解，最后在课程lab里把所看的论文实现。当你把这门课的作业刷完后，你会发现自己实现了一个分布式数据库. 《HDFS-alike in Go》介绍:使用go开发的分布式文件系统. 《What are some good resources for learning about distributed computing? Why?》介绍:Quora上关于学习分布式的资源问答. 《SeaweedFS is a simple and highly scalable distributed file system》介绍:SeaweedFS是使用go开发的分布式文件系统项目,代码简单，逻辑清晰. 《Codis - yet another fast distributed solution for Redis》介绍:Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 《Paper: Coordination Avoidance In Distributed Databases By Peter Bailis》介绍:Coordination Avoidance In Distributed Databases. 《从零开始写分布式数据库》介绍:本文以TiDB 源码为例. 《what we talk about when we talk about distributed systems》介绍:分布式系统概念梳理,为分布式系统涉及的主要概念进行了梳理. 《Distributed locks with Redis》介绍:使用Redis实现分布式锁. 《CS244b: Distributed Systems》介绍: 斯坦福2014年秋季分布式课程. 《RAMP Made Easy》介绍: 分布式的“读原子性”. 《Strategies and Principles of Distributed Machine Learning on Big Data》介绍: 大数据分布式机器学习的策略与原理. 《Distributed Systems: What is the CAP theorem?》介绍: 分布式CAP法则. 《How should I start to learn distributed storage system as a beginner?》介绍: 新手如何步入分布式存储系统. 《Cassandra - A Decentralized Structured Storage System》介绍: 分布式存储系统Cassandra剖析,推荐白皮书Introduction to Apache Cassandra. 《What is the best resource to learn about distributed systems?》介绍: 分布式系统学习资源. 《What are some high performance TCP hacks?》介绍: 一些高性能TCP黑客技巧. 《Maintaining performance in distributed systems》介绍:分布式系统性能提升. 《A simple totally ordered broadcast protocol》介绍:Benjamin Reed 和 Flavio P.Junqueira 所著论文,对Zab算法进行了介绍,zab算法是Zookeeper保持数据一致性的核心,在国内有很多公司都使用zookeeper做为分布式的解决方案.推荐与此相关的一篇文章ZooKeeper’s atomic broadcast protocol: Theory and practice. 《zFS - A Scalable Distributed File System Using Object Disk》介绍:可扩展的分布式文件系统ZFS,The Zettabyte File System,End-to-end Data Integrity for File Systems: A ZFS Case Study. 《A Distributed Haskell for the Modern Web》介绍:分布式Haskell在当前web中的应用. 《Reasoning about Consistency Choices in Distributed Systems》介绍:POPL2016的论文,关于分布式系统一致性选择的论述,POPL所接受的论文,github上已经有人整理. 《Paxos Made Simple》介绍:Paxos让分布式更简单.译文.参考阅读:关于Paxos的历史,understanding Paxos part1,Understanding Paxos – Part 2.Quora: What is a simple explanation of the Paxos algorithm?,Tutorial Summary: Paxos Explained from Scratch,Paxos algorithm explained, part 1: The essentials,Paxos algorithm explained, part 2: Insights 《Consensus Protocols: Paxos》介绍:分布式系统一致性协议:Paxos.参考阅读:关于Paxos的历史 《Consensus on Transaction Commit》介绍：事务提交的一致性探讨. 《The Part-Time Parliaments》介绍:在《The Part-Time Parliament》中描述了基本协议的交互过程。在基本协议的基础上完善各种问题得到了最终的议会协议。 为了让人更容易理解《The Part-Time Parliament》中描述的Paxos算法，Lamport在2001发表了《Paxos Made Simple》，以更平直的口头语言描述了Paxos，而没有包含正式的证明和数学术语。《Paxos Made Simple》中，将算法的参与者更细致的划分成了几个角色：Proposer、Acceptor、Learner。另外还有Leader和Client.参考阅读:关于Paxos的历史 《Paxos Made Practical》介绍:看这篇论文时可以先看看理解Paxos Made Practical. 《PaxosLease: Diskless Paxos for Leases》介绍：PaxosLease：实现租约的无盘Paxos算法,译文. 《Paxos Made Moderately Complex》介绍：Paxos算法实现,译文,同时推荐42 Paxos Made Moderately Complex. 《Hadoop Reading List》介绍：Hadoop学习清单. 《Hadoop Reading List》介绍：Hadoop学习清单. 《2010 NoSQL Summer Reading List》介绍：NoSQL知识清单,里面不仅仅包含了数据库阅读清单还包含了分布式系统资料. 《Raft: Understandable Distributed Consensus》介绍：Raft可视化图帮助理解分布式一致性 《Etcd:Distributed reliable key-value store for the most critical data of a distributed system》介绍：Etcd分布式Key-Value存储引擎 《Understanding Availability》介绍：理解peer-to-peer系统中的可用性究竟是指什么.同时推荐基于 Peer-to-Peer 的分布式存储系统的设计 《Process structuring, synchronization, and recovery using atomic actions》介绍：经典论文 《Programming Languages for Parallel Processing》介绍：并行处理的编程语音 《Analysis of Six Distributed File Systems》介绍：此篇论文对HDFS,MooseFS,iRODS,Ceph,GlusterFS,Lustre六个存储系统做了详细分析.如果是自己研发对应的存储系统推荐先阅读此篇论文 《A Survey of Distributed File Systems》介绍：分布式文件系统综述 《Concepts of Concurrent Programming》介绍：并行编程的概念,同时推荐卡内基梅隆FTP 《Concurrency Control Performance Modeling:Alternatives and Implications》介绍：并发控制性能建模：选择与意义 《Distributed Systems - Concepts and Design 5th Edition》介绍：ebook分布式系统概念与设计 《分布式系统设计的形式方法》介绍：分布式系统设计的形式方法 《互斥和选举算法》介绍：互斥和选举算法 《Actors：A model Of Concurrent Cornputation In Distributed Systems》介绍：经典论文 《Security Engineering: A Guide to Building Dependable Distributed Systems》介绍：如何构建一个安全可靠的分布式系统,About the Author,Bibliography:文献资料,章节访问把链接最后的01换成01-27即可 《15-712 Advanced and Distributed Operating Systems》介绍：卡内基梅隆大学的分布式系统博士生课程主页,有很丰富的资料 《Dapper, Google's Large-Scale Distributed Systems Tracing Infrastructure》介绍：Dapper，大规模分布式系统的跟踪系统,译文,译文对照 《CS262a: Advanced Topics in Computer Systems》介绍：伯克利大学计算机系统进阶课程,内容有深度,涵盖分布式,数据库等内容 《Egnyte Architecture: Lessons Learned In Building And Scaling A Multi Petabyte Distributed System》介绍：PB级分布式系统构建/扩展经验 《CS162: Operating Systems and Systems Programming》介绍：伯克利大学计算机系统课程:操作系统与系统编程 《MDCC: Multi-Data Center Consistency》介绍：MDCC主要解决跨数据中心的一致性问题中间件,一种新的协议 《Research at Google:Distributed Systems and Parallel Computing》介绍：google公开对外发表的分布式系统与并行计算论文 《HDFS Architecture Guide》介绍：分布式文件系统HDFS架构 《ActorDB distributed SQL database》介绍：分布式 Key/Value数据库 《An efficient data location protocol for self-organizing storage clusters》介绍：是著名的Ceph的负载平衡策略，文中提出的几种策略都值得尝试，比较赞的一点是可以对照代码体会和实践,如果你还需要了解可以看看Ceph:一个 Linux PB 级分布式文件系统,除此以外,论文的引用部分也挺值得阅读的,同时推荐Ceph: A Scalable, High-Performance Distributed File System 《A Self-Organizing Storage Cluster for Parallel Data-Intensive Applications》介绍：Surrento的冷热平衡策略就采用了延迟写技术 《HBA: Distributed Metadata Management for Large Cluster-Based Storage Systems》介绍：对于分布式存储系统的元数据管理. 《Server-Side I/O Coordination for Parallel File Systems》介绍：服务器端的I/O协调并行文件系统处理,网络,文件存储等都会涉及到IO操作.不过里面涉及到很多技巧性的思路在实践时需要斟酌 《Distributed File Systems: Concepts and Examples》介绍：分布式文件系统概念与应用 《CSE 221: Graduate Operating Systems》介绍：加利福尼亚大学的研究生操作系统课程主页，论文很值得阅读 《S4: Distributed Stream Computing Platform》介绍：Yahoo出品的流式计算系统，目前最流行的两大流式计算系统之一（另一个是storm），Yahoo的主要广告计算平台 《Pregel: a system for large-scale graph processing》介绍：Google的大规模图计算系统，相当长一段时间是Google PageRank的主要计算系统，对开源的影响也很大（包括GraphLab和GraphChi） 《GraphLab: A New Framework for Parallel Machine Learning》介绍：CMU基于图计算的分布式机器学习框架，目前已经成立了专门的商业公司，在分布式机器学习上很有两把刷子，其单机版的GraphChi在百万维度的矩阵分解都只需要2~3分钟； 《F1: A Distributed SQL Database That Scales》介绍：这篇论文是Google 2013年发表的，介绍了F1的架构思路，13年时就开始支撑Google的AdWords业务，另外两篇介绍文章F1 - The Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business .Google NewSQL之F1 《Cockroach DB:A Scalable, Survivable, Strongly-Consistent SQL Database》介绍：CockroachDB ：一个可伸缩的、跨地域复制的，且支持事务的数据存储,InfoQ介绍,Design and Architecture of CockroachDb 《Multi-Paxos: An Implementation and Evaluation》介绍：Multi-Paxos实现与总结，此外推荐Paxos/Multi-paxos Algorithm,Multi-Paxos Example，地址:ftp://ftp.cs.washington.edu/tr/2009/09/UW-CSE-09-09-02.PDF 《Zab: High-performance broadcast for primary-backup systems》介绍：一致性协议zab分析 《A Distributed Hash Table》介绍：分布式哈希算法论文,扩展阅读Introduction to Distributed Hash Tables,Distributed Hash Tables 《Comparing the performance of distributed hash tables under churn》介绍：分布式hash表性能的Churn问题 《Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web》介绍：分布式系统的CAP问题,推荐Perspectives on the CAP Theorem.对CAP理论的解析文章,PODC ppt,A plain english introduction to CAP Theorem,IEEE Computer issue on the CAP Theorem 《F2FS: A New File System for Flash Storage》介绍：闪存存储文件系统F2FS 《Better I/O Through Byte-Addressable, Persistent Memory》介绍：微软发表的关于i/o访问优化论文 《tmpfs: A Virtual Memory File System》介绍：虚拟内存文件系统tmpfs 《BTRFS: The Linux B-tree Filesystem》介绍：Linux B-tree文件系统. 《Akamai technical publication》介绍：Akamai是全球最大的云计算机平台之一，承载了全球15-30%网络流量,如果你是做CDN或者是云服务,这个里面的论文会给你很有帮助.例如这几天看facebook开源的osquery。找到通过db的方式运维,找到Keeping Track of 70,000+ Servers: The Akamai Query System这篇论文，先看论文领会思想，然后再使用工具osquery实践 《BASE: An Acid Alternative》介绍：来自eBay 的解决方案,译文Base: 一种Acid的替代方案,应用案例参考保证分布式系统数据一致性的6种方案 《A Note on Distributed Computing》介绍：Jim Waldo和Sam Kendall等人共同撰写了一篇非常有名的论文“分布式计算备忘录”，这篇论文在Reddit上被人推荐为“每个程序员都应当至少读上两篇”的论文。在这篇论文中，作者表示“忽略本地计算与分布式计算之间的区别是一种危险的思想”，特别指出了Emerald、Argus、DCOM以及CORBA的设计问题。作者将这些设计问题归纳为“三个错误的原则”： “对于某个应用来说，无论它的部署环境如何，总有一种单一的、自然的面向对象设计可以符合其需求。” “故障与性能问题与某个应用的组件实现直接相关，在最初的设计中无需考虑这些问题。” “对象的接口与使用对象的上下文无关”. 《Distributed Systems Papers》介绍：分布式系统领域经典论文列表. 《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web》介绍：Consistent Hashing算法描述. 《SIGMOD 2016: Accepted Research Papers》介绍：SIGMOD是世界上最有名的数据库会议之一,最具有权威性,收录论文审核非常严格.2016年的SIGMOD 会议照常进行,上面收录了今年SIGMOD收录的论文,把题目输入google中加上pdf就能找到,很多论文值得阅读,SIGMOD 2015 《Notes on CPSC 465/565: Theory of Distributed Systems》介绍:耶鲁大学的分布式系统理论课程笔记 《Distributed Operating System Doc PDF》介绍:分布式系统文档资源（可下载） 《Anatomy of a database system》介绍:数据库系统剖析，这本书是由伯克利大学的Joseph M. Hellerstein和M. Stonebraker合著的一篇论文.对数据库剖析很有深度.除此以外还有一篇文章Architecture of a Database System。数据库系统架构,厦门大学的数据库实验室教授林子雨组织过翻译 《A Relational Model of Data for Large Shared Data Banks》介绍:数据库关系模型论文 《RUC Innovative data systems reaserch lab recommand papers》介绍:中国人民大学数据研究实验室推荐的数据库领域论文 《A Scalable Distributed Information Management System》介绍:构建可扩展的分布式信息管理系统 《Distributed Systems in Haskell》介绍:Haskell中的分布式系统开发 《Large-scale cluster management at Google with Borg》介绍:Google使用Borg进行大规模集群的管理,伯克利大学ppt介绍,中文版 《Lock Free Programming Practice》介绍:并发编程（Concurrency Programming）资料,主要涵盖lock free数据结构实现、内存回收方法、memory model等备份链接 密码: xc5j 《Distributed Algorithms Lecture Notes for 6.852》介绍:Nancy Lynch's的分布式算法研究生课程讲义 《Distributed Algorithms for Topic Models》介绍:分布式算法主题模型. 《RecSys - ACM Recommender Systems》介绍:世界上非常有名的推荐系统会议，我比较推荐接收的PAPER 《All Things Distributed》介绍:推荐一个博客,博主是Amazon CTO Werner Vogels,这是一个关注分布式领域的博客.大部分博文是关于在工业界应用. 《programming, database, distributed system resource list》介绍:这个Git是由阿里(alibaba)的技术专家何登成维护,主要是分布式数据库. 《Making reliable distributed systems in the presence of sodware errors》介绍:Erlang的作者Joe Armstrong撰写的论文，面对软件错误构建可靠的分布式系统.中文译版 《CS 525: Advanced Distributed Systems[Spring 2016]》介绍:伊利诺伊大学的Advanced Distributed Systems 里把各个方向重要papers（updated Spring 2015）列举出来，可以参考一下 《Distributed Algorithms》介绍:这是一本分布式算法电子书,作者是Jukka Suomela.讲述了多个计算模型,一致性,唯一标示,并发等. 《TinyLFU: A Highly Efficient Cache Admission Policy》介绍:当时是在阅读如何设计一个缓存系统时看到的，然后通过Google找到了这一篇关于缓存策略的论文，它是LFU的改良版,中文介绍.如果有兴趣可以看看Golang实现版。结合起来可能会帮助你理解 《6.S897: Large-Scale Systems》介绍:斯坦福大学给研究生开的分布式系统课程。教师是 spark 作者 matei. 能把这些内容真正理解透，分布式系统的功力就很强了。 《学习分布式系统需要怎样的知识？》介绍:[怎么学系列]学习分布式系统需要怎样的知识？ 《Distributed systems theory for the distributed systems engineer》介绍:分布式系统工程师的分布式系统理论 《A Distributed Systems Reading List》介绍:分布式系统论文阅读列表 《Distributed Systems Reading Group》介绍:麻省理工大学分布式系统小组，他们会把平时阅读到的优秀论文分享出来。虽然有些论文本页已经收录，但是里面的安排表schedule还是挺赞的 《Scalable Software Architecture》介绍:分布式系统、可扩展性与系统设计相关报告、论文与网络资源汇总. 《MapReduce&Hadoop resource》介绍:MapReduce&Hadoop相关论文，涉及分布式系统设计，性能分析，实践，优化等多个方面 《Distributed Systems: Principles and Paradigms(second edtion)》介绍:分布式系统原理与范型第二版,课后解答 《Distributed Systems Seminar's reading list for Spring 2017》介绍:分布式系统研讨会论文阅读列表 《A Critique of the CAP Theorem》介绍:这是一篇评论CAP定理的论文，学习CAP很有帮助,推荐阅读评论文章"A Critique of the CAP Theorem" 《Evolving Distributed Systems》介绍:推荐文章不断进化的分布式系统.

分布式事务的解决方案有如下几种： 全局消息基于可靠消息服务的分布式事务TCC最大努力通知方案1：全局事务（DTP模型）全局事务基于DTP模型实现。DTP是由X/Open组织提出的一种分布式事务模型——X/Open Distributed Transaction Processing Reference Model。它规定了要实现分布式事务，需要三种角色： AP：Application 应用系统 它就是我们开发的业务系统，在我们开发的过程中，可以使用资源管理器提供的事务接口来实现分布式事务。 TM：Transaction Manager 事务管理器 分布式事务的实现由事务管理器来完成，它会提供分布式事务的操作接口供我们的业务系统调用。这些接口称为TX接口。事务管理器还管理着所有的资源管理器，通过它们提供的XA接口来同一调度这些资源管理器，以实现分布式事务。DTP只是一套实现分布式事务的规范，并没有定义具体如何实现分布式事务，TM可以采用2PC、3PC、Paxos等协议实现分布式事务。RM：Resource Manager 资源管理器 能够提供数据服务的对象都可以是资源管理器，比如：数据库、消息中间件、缓存等。大部分场景下，数据库即为分布式事务中的资源管理器。资源管理器能够提供单数据库的事务能力，它们通过XA接口，将本数据库的提交、回滚等能力提供给事务管理器调用，以帮助事务管理器实现分布式的事务管理。XA是DTP模型定义的接口，用于向事务管理器提供该资源管理器(该数据库)的提交、回滚等能力。DTP只是一套实现分布式事务的规范，RM具体的实现是由数据库厂商来完成的。有没有基于DTP模型的分布式事务中间件？DTP模型有啥优缺点？方案2：基于可靠消息服务的分布式事务这种实现分布式事务的方式需要通过消息中间件来实现。假设有A和B两个系统，分别可以处理任务A和任务B。此时系统A中存在一个业务流程，需要将任务A和任务B在同一个事务中处理。下面来介绍基于消息中间件来实现这种分布式事务。 title 在系统A处理任务A前，首先向消息中间件发送一条消息消息中间件收到后将该条消息持久化，但并不投递。此时下游系统B仍然不知道该条消息的存在。消息中间件持久化成功后，便向系统A返回一个确认应答；系统A收到确认应答后，则可以开始处理任务A；任务A处理完成后，向消息中间件发送Commit请求。该请求发送完成后，对系统A而言，该事务的处理过程就结束了，此时它可以处理别的任务了。 但commit消息可能会在传输途中丢失，从而消息中间件并不会向系统B投递这条消息，从而系统就会出现不一致性。这个问题由消息中间件的事务回查机制完成，下文会介绍。消息中间件收到Commit指令后，便向系统B投递该消息，从而触发任务B的执行；当任务B执行完成后，系统B向消息中间件返回一个确认应答，告诉消息中间件该消息已经成功消费，此时，这个分布式事务完成。上述过程可以得出如下几个结论： 消息中间件扮演者分布式事务协调者的角色。 系统A完成任务A后，到任务B执行完成之间，会存在一定的时间差。在这个时间差内，整个系统处于数据不一致的状态，但这短暂的不一致性是可以接受的，因为经过短暂的时间后，系统又可以保持数据一致性，满足BASE理论。 上述过程中，如果任务A处理失败，那么需要进入回滚流程，如下图所示： title 若系统A在处理任务A时失败，那么就会向消息中间件发送Rollback请求。和发送Commit请求一样，系统A发完之后便可以认为回滚已经完成，它便可以去做其他的事情。消息中间件收到回滚请求后，直接将该消息丢弃，而不投递给系统B，从而不会触发系统B的任务B。此时系统又处于一致性状态，因为任务A和任务B都没有执行。 上面所介绍的Commit和Rollback都属于理想情况，但在实际系统中，Commit和Rollback指令都有可能在传输途中丢失。那么当出现这种情况的时候，消息中间件是如何保证数据一致性呢？——答案就是超时询问机制。 title 系统A除了实现正常的业务流程外，还需提供一个事务询问的接口，供消息中间件调用。当消息中间件收到一条事务型消息后便开始计时，如果到了超时时间也没收到系统A发来的Commit或Rollback指令的话，就会主动调用系统A提供的事务询问接口询问该系统目前的状态。该接口会返回三种结果： 提交 若获得的状态是“提交”，则将该消息投递给系统B。回滚 若获得的状态是“回滚”，则直接将条消息丢弃。处理中 若获得的状态是“处理中”，则继续等待。消息中间件的超时询问机制能够防止上游系统因在传输过程中丢失Commit/Rollback指令而导致的系统不一致情况，而且能降低上游系统的阻塞时间，上游系统只要发出Commit/Rollback指令后便可以处理其他任务，无需等待确认应答。而Commit/Rollback指令丢失的情况通过超时询问机制来弥补，这样大大降低上游系统的阻塞时间，提升系统的并发度。 下面来说一说消息投递过程的可靠性保证。 当上游系统执行完任务并向消息中间件提交了Commit指令后，便可以处理其他任务了，此时它可以认为事务已经完成，接下来消息中间件一定会保证消息被下游系统成功消费掉！那么这是怎么做到的呢？这由消息中间件的投递流程来保证。 消息中间件向下游系统投递完消息后便进入阻塞等待状态，下游系统便立即进行任务的处理，任务处理完成后便向消息中间件返回应答。消息中间件收到确认应答后便认为该事务处理完毕！ 如果消息在投递过程中丢失，或消息的确认应答在返回途中丢失，那么消息中间件在等待确认应答超时之后就会重新投递，直到下游消费者返回消费成功响应为止。当然，一般消息中间件可以设置消息重试的次数和时间间隔，比如：当第一次投递失败后，每隔五分钟重试一次，一共重试3次。如果重试3次之后仍然投递失败，那么这条消息就需要人工干预。 title title 有的同学可能要问：消息投递失败后为什么不回滚消息，而是不断尝试重新投递？ 这就涉及到整套分布式事务系统的实现成本问题。 我们知道，当系统A将向消息中间件发送Commit指令后，它便去做别的事情了。如果此时消息投递失败，需要回滚的话，就需要让系统A事先提供回滚接口，这无疑增加了额外的开发成本，业务系统的复杂度也将提高。对于一个业务系统的设计目标是，在保证性能的前提下，最大限度地降低系统复杂度，从而能够降低系统的运维成本。 不知大家是否发现，上游系统A向消息中间件提交Commit/Rollback消息采用的是异步方式，也就是当上游系统提交完消息后便可以去做别的事情，接下来提交、回滚就完全交给消息中间件来完成，并且完全信任消息中间件，认为它一定能正确地完成事务的提交或回滚。然而，消息中间件向下游系统投递消息的过程是同步的。也就是消息中间件将消息投递给下游系统后，它会阻塞等待，等下游系统成功处理完任务返回确认应答后才取消阻塞等待。为什么这两者在设计上是不一致的呢？ 首先，上游系统和消息中间件之间采用异步通信是为了提高系统并发度。业务系统直接和用户打交道，用户体验尤为重要，因此这种异步通信方式能够极大程度地降低用户等待时间。此外，异步通信相对于同步通信而言，没有了长时间的阻塞等待，因此系统的并发性也大大增加。但异步通信可能会引起Commit/Rollback指令丢失的问题，这就由消息中间件的超时询问机制来弥补。 那么，消息中间件和下游系统之间为什么要采用同步通信呢？ 异步能提升系统性能，但随之会增加系统复杂度；而同步虽然降低系统并发度，但实现成本较低。因此，在对并发度要求不是很高的情况下，或者服务器资源较为充裕的情况下，我们可以选择同步来降低系统的复杂度。 我们知道，消息中间件是一个独立于业务系统的第三方中间件，它不和任何业务系统产生直接的耦合，它也不和用户产生直接的关联，它一般部署在独立的服务器集群上，具有良好的可扩展性，所以不必太过于担心它的性能，如果处理速度无法满足我们的要求，可以增加机器来解决。而且，即使消息中间件处理速度有一定的延迟那也是可以接受的，因为前面所介绍的BASE理论就告诉我们了，我们追求的是最终一致性，而非实时一致性，因此消息中间件产生的时延导致事务短暂的不一致是可以接受的。 方案3：最大努力通知（定期校对）最大努力通知也被称为定期校对，其实在方案二中已经包含，这里再单独介绍，主要是为了知识体系的完整性。这种方案也需要消息中间件的参与，其过程如下： title 上游系统在完成任务后，向消息中间件同步地发送一条消息，确保消息中间件成功持久化这条消息，然后上游系统可以去做别的事情了；消息中间件收到消息后负责将该消息同步投递给相应的下游系统，并触发下游系统的任务执行；当下游系统处理成功后，向消息中间件反馈确认应答，消息中间件便可以将该条消息删除，从而该事务完成。上面是一个理想化的过程，但在实际场景中，往往会出现如下几种意外情况： 消息中间件向下游系统投递消息失败上游系统向消息中间件发送消息失败对于第一种情况，消息中间件具有重试机制，我们可以在消息中间件中设置消息的重试次数和重试时间间隔，对于网络不稳定导致的消息投递失败的情况，往往重试几次后消息便可以成功投递，如果超过了重试的上限仍然投递失败，那么消息中间件不再投递该消息，而是记录在失败消息表中，消息中间件需要提供失败消息的查询接口，下游系统会定期查询失败消息，并将其消费，这就是所谓的“定期校对”。 如果重复投递和定期校对都不能解决问题，往往是因为下游系统出现了严重的错误，此时就需要人工干预。 对于第二种情况，需要在上游系统中建立消息重发机制。可以在上游系统建立一张本地消息表，并将 任务处理过程 和 向本地消息表中插入消息 这两个步骤放在一个本地事务中完成。如果向本地消息表插入消息失败，那么就会触发回滚，之前的任务处理结果就会被取消。如果这量步都执行成功，那么该本地事务就完成了。接下来会有一个专门的消息发送者不断地发送本地消息表中的消息，如果发送失败它会返回重试。当然，也要给消息发送者设置重试的上限，一般而言，达到重试上限仍然发送失败，那就意味着消息中间件出现严重的问题，此时也只有人工干预才能解决问题。 对于不支持事务型消息的消息中间件，如果要实现分布式事务的话，就可以采用这种方式。它能够通过重试机制+定期校对实现分布式事务，但相比于第二种方案，它达到数据一致性的周期较长，而且还需要在上游系统中实现消息重试发布机制，以确保消息成功发布给消息中间件，这无疑增加了业务系统的开发成本，使得业务系统不够纯粹，并且这些额外的业务逻辑无疑会占用业务系统的硬件资源，从而影响性能。 因此，尽量选择支持事务型消息的消息中间件来实现分布式事务，如RocketMQ。 方案4：TCC（两阶段型、补偿型）TCC即为Try Confirm Cancel，它属于补偿型分布式事务。顾名思义，TCC实现分布式事务一共有三个步骤： Try：尝试待执行的业务 这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的全部资源Confirm：执行业务 这个过程真正开始执行业务，由于Try阶段已经完成了一致性检查，因此本过程直接执行，而不做任何检查。并且在执行的过程中，会使用到Try阶段预留的业务资源。Cancel：取消执行的业务 若业务执行失败，则进入Cancel阶段，它会释放所有占用的业务资源，并回滚Confirm阶段执行的操作。下面以一个转账的例子来解释下TCC实现分布式事务的过程。 假设用户A用他的账户余额给用户B发一个100元的红包，并且余额系统和红包系统是两个独立的系统。 Try 创建一条转账流水，并将流水的状态设为交易中将用户A的账户中扣除100元（预留业务资源）Try成功之后，便进入Confirm阶段Try过程发生任何异常，均进入Cancel阶段Confirm 向B用户的红包账户中增加100元将流水的状态设为交易已完成Confirm过程发生任何异常，均进入Cancel阶段Confirm过程执行成功，则该事务结束Cancel 将用户A的账户增加100元将流水的状态设为交易失败在传统事务机制中，业务逻辑的执行和事务的处理，是在不同的阶段由不同的部件来完成的：业务逻辑部分访问资源实现数据存储，其处理是由业务系统负责；事务处理部分通过协调资源管理器以实现事务管理，其处理由事务管理器来负责。二者没有太多交互的地方，所以，传统事务管理器的事务处理逻辑，仅需要着眼于事务完成（commit/rollback）阶段，而不必关注业务执行阶段。 TCC全局事务必须基于RM本地事务来实现全局事务TCC服务是由Try/Confirm/Cancel业务构成的， 其Try/Confirm/Cancel业务在执行时，会访问资源管理器（Resource Manager，下文简称RM）来存取数据。这些存取操作，必须要参与RM本地事务，以使其更改的数据要么都commit，要么都rollback。 这一点不难理解，考虑一下如下场景： title 假设图中的服务B没有基于RM本地事务（以RDBS为例，可通过设置auto-commit为true来模拟），那么一旦[B:Try]操作中途执行失败，TCC事务框架后续决定回滚全局事务时，该[B:Cancel]则需要判断[B:Try]中哪些操作已经写到DB、哪些操作还没有写到DB：假设[B:Try]业务有5个写库操作，[B:Cancel]业务则需要逐个判断这5个操作是否生效，并将生效的操作执行反向操作。 不幸的是，由于[B:Cancel]业务也有n（0<=n<=5）个反向的写库操作，此时一旦[B:Cancel]也中途出错，则后续的[B:Cancel]执行任务更加繁重。因为，相比第一次[B:Cancel]操作，后续的[B:Cancel]操作还需要判断先前的[B:Cancel]操作的n（0<=n<=5）个写库中哪几个已经执行、哪几个还没有执行，这就涉及到了幂等性问题。而对幂等性的保障，又很可能还需要涉及额外的写库操作，该写库操作又会因为没有RM本地事务的支持而存在类似问题。。。可想而知，如果不基于RM本地事务，TCC事务框架是无法有效的管理TCC全局事务的。 反之，基于RM本地事务的TCC事务，这种情况则会很容易处理：[B:Try]操作中途执行失败，TCC事务框架将其参与RM本地事务直接rollback即可。后续TCC事务框架决定回滚全局事务时，在知道“[B:Try]操作涉及的RM本地事务已经rollback”的情况下，根本无需执行[B:Cancel]操作。 换句话说，基于RM本地事务实现TCC事务框架时，一个TCC型服务的cancel业务要么执行，要么不执行，不需要考虑部分执行的情况。 TCC事务框架应该提供Confirm/Cancel服务的幂等性保障一般认为，服务的幂等性，是指针对同一个服务的多次(n>1)请求和对它的单次(n=1)请求，二者具有相同的副作用。 在TCC事务模型中，Confirm/Cancel业务可能会被重复调用，其原因很多。比如，全局事务在提交/回滚时会调用各TCC服务的Confirm/Cancel业务逻辑。执行这些Confirm/Cancel业务时，可能会出现如网络中断的故障而使得全局事务不能完成。因此，故障恢复机制后续仍然会重新提交/回滚这些未完成的全局事务，这样就会再次调用参与该全局事务的各TCC服务的Confirm/Cancel业务逻辑。 既然Confirm/Cancel业务可能会被多次调用，就需要保障其幂等性。 那么，应该由TCC事务框架来提供幂等性保障？还是应该由业务系统自行来保障幂等性呢？ 个人认为，应该是由TCC事务框架来提供幂等性保障。如果仅仅只是极个别服务存在这个问题的话，那么由业务系统来负责也是可以的；然而，这是一类公共问题，毫无疑问，所有TCC服务的Confirm/Cancel业务存在幂等性问题。TCC服务的公共问题应该由TCC事务框架来解决；而且，考虑一下由业务系统来负责幂等性需要考虑的问题，就会发现，这无疑增大了业务系统的复杂度。

当然要批量导入啊。 excel转换成特定SQL文件然后导入数据库。 这里去重，可以考虑一张临时表。 然后插入数据可以使用如mysql的ignore : insert ignore into table_main(id,phone,other)  select id,phone,other from table_temp_uuid; ###### 引用来自“vvtf”的评论 当然要批量导入啊。 excel转换成特定SQL文件然后导入数据库。 这里去重，可以考虑一张临时表。 然后插入数据可以使用如mysql的 ignore : insert ignore into table_main(id,phone,other)  select id,phone,other from table_temp_uuid; 临时表方案靠谱。###### 首先，判断重复用数据库的uniq来做（程序里处理uniq的报错），而不是自己写代码另外去判断。 大数据量的导入建议用csv，读一行导一行，内存占用小。如果非要用excel，记得服务器内存要设置大点。 ######你说的那两个字段加入唯一约束 . 然后开启事务,循环插入,如果插入失败,则改为更新(或你自己的逻辑). 这样快,但肯定很消耗CPU. ######为什么不在list里面去重，再一次导入######这样数据库只需要批量插入的时候维护一次索引，如果修改的其他字段没建索引，那么update是不需要维护索引的######看能不能插入之前拆出2个list，一个是重复的，一个是不重复的（这样拆之前需要select……for update，防止其他事务修改数据）###### 引用来自“death_rider”的评论 为什么不在list里面去重，再一次导入 赞同。具体设计问题不明确不好给意见。不过系统和算法设计中有点是可以肯定的：逻辑处理和数据载入尽量分开。 在单纯的算法设计中，往往不会去考虑数据迁移的成本，这是比较理科的分析方式，而在系统开发过程中，数据迁移的成本是必须要考虑的，这是工程化的必然。 数据迁移，这里是广义上的，包括，数据的转移，从磁盘到外部存储（主板上所谓的内存），从外部存储到片内存储（soc，cpu的内部cache,差异在于无需外部总线）；也包括，通过网络在不同处理设备之间的转移；同时还包括数据的结构调整，如数据清洗在逻辑层面的工作。 楼主应该考虑数据的预清洗或后处理。当然具体用哪种更合适，还要自己根据数据的来源，数据之间的关联性，数据处理的实时性等要求来判断。 哈，反正是个系统设计层面的工作。不是工具选择层面的事务。 ######回复 @首席打酱油 : 把需要比对的，做md5等散列数据，可把大概率数据测出来。只有命中时才进行比对。这些工作，需要额外的数据组织，同时需要额外的编程。这些数据过滤的算法，如果用c我看不出有啥太大计算量。######目测楼主说的不能重复不仅是指Excle中的数据不能重复，而且还要Excel中的数据和现有数据库中的数据不能重复，所以不能单纯的把Excle中的数据加载到List中内存去重###### 引用来自“vvtf”的评论 当然要批量导入啊。 excel转换成特定SQL文件然后导入数据库。 这里去重，可以考虑一张临时表。 然后插入数据可以使用如mysql的 ignore : insert ignore into table_main(id,phone,other)  select id,phone,other from table_temp_uuid; 一般怎么把EXCEL转换成SQL文件呢？######如果你的excel本来就是符合load data infile的文件格式， 都不需要解析的。######就是解析excel啊。所以这个方案的耗时也就是解析excel这里。当然这可能也浪费不了多少时间的。 我这里是对MySQL的方案。 解析成对应的MySQL能解析的。比如load data infile。 或者批量insert也行。 然后source。6W条瞬间插入的。######数据直接用com接口导出（服务器处理），分布式处理也行，但是不做任何处理，极限速度，10w体积很小的，1m?连1个高清png的大小都没有，数据也是可以压缩的，重复的数据会压缩很多，上传和带宽不是瓶颈，主要是数据逻辑处理和数据库瓶颈，你处理的时候解析到内存，一个瓶颈，倒入数据库又temp table，还是内存，数据库的内存，又一个瓶颈######你要懂服务器编程才行啊，很多处理单机导出数据还可以，服务器就不这么处理了，还有就是数据库，知道temp table，stor procedure,导入导出，那是数据库初级而已######主要问题在“ Excel文档转List花费4m”，只能异步了。

　TTS</B>是Text To Speech的缩写，即“从文本到语音”。它是同时运用语言学和心理学的杰出之作，在内置芯片的支持之下，通过神经网络的设计，把文字智能地转化为自然语音流。TTS技术对文本文件进行实时转换，转换时间之短可以秒计算。在其特有智能语音控制器作用下，文本输出的语音音律流畅，使得听者在听取信息时感觉自然，毫无机器语音输出的冷漠与生涩感。TTS语音合成技术即将覆盖国标一、二级汉字，具有英文接口，自动识别中、英文，支持中英文混读。所有声音采用真人普通话为标准发音，实现了120-150个汉字/秒的快速语音合成，朗读速度达3-4个汉字/秒，使用户可以听到清晰悦耳的音质和连贯流畅的语调。现在有少部分MP3随身听具有了TTS功能。 　　TTS是语音合成应用的一种，它将储存于电脑中的文件，如帮助文件或者网页，转换成自然语音输出。TTS可以帮助有视觉障碍的人阅读计算机上的信息，或者只是简单的用来增加文本文档的可读性。现在的TTL应用包括语音驱动的邮件以及声音敏感系统。TTS经常与声音识别程序一起使用。现在有很多TTS的产品，包括Read Please 2000， Proverbe Speech Unit，以及Next Up Technology的TextAloud。朗讯、 Elan、以及 AT&T都有自己的语音合成产品。 　　除了TTS软件之外，很多商家还提供硬件产品，其中包括以色列WizCom Technologies公司的 Quick Link Pen，它是一个笔状的可以扫描也可以阅读文字的设备；还有Ostrich Software公司的Road Runner，一个手持的可以阅读ASCII文本的设备；另外还有美国DEC公司的DecTalk TTS，它是可以替代声卡的外部硬件设备，它包含一个内部软件设备，可以与个人电脑自己的声卡协同工作。 TTS文语转换用途很广，包括电子邮件的阅读、IVR系统的语音提示等等，目前IVR系统已广泛应用于各个行业（如电信、交通运输等）。 　　TTS所用的关键技术就是语音合成(SpeechSynthesis)。早期的TTS一般采用专用的芯片实现，如德州仪器公司的TMS50C10/TMS50C57、飞利浦的PH84H36等，但主要用在家用电器或儿童玩具中。 　　而基于微机应用的TTS一般用纯软件实现，主要包括以下几部分： 　　●文本分析-对输入文本进行语言学分析，逐句进行词汇的、语法的和语义的分析，以确定句子的低层结构和每个字的音素的组成，包括文本的断句、字词切分、多音字的处理、数字的处理、缩略语的处理等。 　　●语音合成-把处理好的文本所对应的单字或短语从语音合成库中提取，把语言学描述转化成言语波形。 　　●韵律处理-合成音质(Qualityof Synthetic Speech)是指语音合成系统所输出的语音的质量，一般从清晰度(或可懂度)、自然度和连贯性等方面进行主观评价。清晰度是正确听辨有意义词语的百分率；自然度用来评价合成语音音质是否接近人说话的声音，合成词语的语调是否自然； 连贯性用来评价合成语句是否流畅。 　　要合成出高质量的语音，所采用的算法是极为复杂的，因此对机器的要求也非常高。算法的复杂度决定了目前微机并发进行多通道TTS的系统容量。 在一般的CTI应用系统中，都会有IVR（交互式语音应答系统）。IVR系统是呼叫中心的重要组成部分，通过IVR系统，用户可以利用音频按健电话输入信息，从系统中获得预先录制的数字或合成语音信息。具有TTS功能的IVR可以加快服务速度，节约服务成本，使IVR为呼叫者提供7*24小时的服务。 　　目前常见的IVR系统大都是通用的工控机平台上插入语音板卡组成，并支持中文语音合成TTS等技术。 　　一个典型的包含TTS服务的电话服务流程可分为： 　　用户电话拨入，系统IVR响应，获得用户按键等信息。 　　IVR根据用户的按键信息，向数据库服务器申请相关数据。 　　数据库服务器返回文本数据给IVR。 　　IVR通过其TCP通讯接口，将需要合成的文本信息发送给TTS服务器。 　　TTS服务器将用户文本合成的语音数据分段通过TCP通讯接口发送给IVR服务器。 　　IVR服务器把分段语音数据组装成为独立的语音文件。 　　IVR播放相应的语音文件给电话用户。 　　一般的公网接入（IVR）大都采用工控机+语音板卡，而合成的语音数据则通过局域网传给IVR。这种结构只适用于简单的应用场合。 包括中文语音处理和语音合成，利用中文韵律等相关知识对中文语句进行分词、词性判断、注音、数字符号转换，语音合成通过查询中文语音库得到语音。目前中文TTS系统，比较著名的有：IBM，Microsoft，Fujitsu，科大讯飞，捷通华声等研究的系统。目前比较关键的就是中文韵律处理、符号数字、多音字、构词方面有较多的问题，需要不断研究，使得中文语音合成的自然化程度较高。 　CTI技术使电信和计算机相互融合，克服了传统电信和计算机服务相对单一的缺点，将两者完美结合了起来。其应用领域非常广泛，任何需要语音、数据通信，特别是那些希望把计算机网与通信网结合起来完成语音数据信息交换的系统都会用到CTI技术。 　　TTS即语音合成技术(Text To Speech)，它涉及声学、语言学、数学信号处理技术、多媒体技术等多个学科技术，是中文信息处理领域的一项前沿技术，实现把计算机中任意出现的文字转换成自然流畅的语音输出。 　　TTS在CTI系统中可以应用在IVR（交互式语音应答）服务器上，以提供语音交互式平台，为用户电话来访提供语音提示，引导用户选择服务内容和输入电话事务所需的数据，并接受用户在电话拨号键盘上输入的信息，实现对计算机数据库等信息资料的交互式访问。 　　在IVR中应用TTS可以自动将文本信息转换为语音文件，或者实时地将文本信息合成语音并通过电话发布。实现文本与语音自动双向转换，以达到人与系统的自动交互，随时随地为客户服务。维护人员不必再人工录音，只须将电子文档引入系统中，系统可以自动将电子文档转换为语音信息播放给客户。数据库中存放的大量数据，无需事先进行录音，能够随时根据查询条件查出并合成语音进行播报，从而大大减少了座席人员的工作负担。 　　那么应如何将TTS功能附加到CTI应用中呢？某些比较先进的交换平台，已经在交换机的内部实现了TTS的功能，并作为标准接口的一部分对外提供，业务开发商只需要简单的调用他们即可以在业务中使用该功能。 　　对于未实现TTS功能的PBX，就需要业务开发商自己去选择合适的平台，在此基础上进行二次开发，即调用所选TTS平台提供的标准接口，实现语音合成功能。 　　目前CTI已经成为全球发展最为迅猛的产业之一，每年以50%的速度增长，CTI如同计算机产业一样是一个金字塔形的产业链，从上到下会以至少20倍的幅度增值。TTS作为一种诱人的新技术，如果能很好的嵌入到增值业务的应用中去，必将形成一个更好的应用前景。 　　杭州音通软件有限公司是由国家教育部和浙江省人民政府联办并依托浙江大学而成立的高新技术公司，音通公司主要致力于计算机语音技术的研发并逐步开拓语音识别、语音流媒体传输等其它语音领域的研究。其核心技术（Intone＿TTS）是具有自主知识产权的中文语音合成技术，在由浙江省科技厅组织的鉴定中被专家一致鉴定为国内领先地位，并已申请多项国家专利。 　　Intone_TTS是一套把文本信息转换为语音信息的开发工具包，为系统集成商、软件开发商提供了完备的接口函数和编程示例，使用户能够灵活的进行调用，并集成到其它应用系统中。接口需要语音合成运行库的支持，适合多种开发环境。开发者可以根据具体的应用场合进行选择。 　　它能够对所有的汉字、英文、阿拉伯数字进行语音合成； 　　支持繁体字及多音字的编辑； 　　合成效果：自然、平滑； 　　规范的函数调用接口，同时支持微软SAPI的调用；支持同步调用和异步调用方式； 　　支持PCM Wave，uLaw/aLaw Wave，ADPCM，Dialogic Vox等多种语音格式； 　　支持GB2312码（简体中文）、BIG5码（繁体）、UNICODE码； 　　支持多路通道同时合成； 　　支持Dialogic、东进、三汇等主流语音板卡； TTS就是Text To Speech，文本转语音，文本朗读，差不多是一个意思。在语音系统开发中经常要用到。 　　目前市场上的TTS很多，实现方式也各式各样，有的很昂贵，如科大讯飞，据说当初得到863计划的资助，有很高的技术；有的相对便宜，如捷通华声, InfoTalk；也有免费的，如微软的TTS产品。 　　相对于ASR（Automatic Speech Recognition，自动语音识别）来说，实现一个TTS产品所需要的技术难度不算大，在我看来也就是个力气活。 　　要是让我们来做一个能够把汉语句子朗读出来的TTS，我们会怎么做呢？ 　　有一种最简单的TTS，就是把每个字都念出来，你会问，岂不要录制6千多个汉字的语音？幸运的是，汉语的音节很少，很多同音字。我们最多只是需要录制： 声母数×韵母数×4，（其实不是每个读音都有4声），这样算来，最多只需要录制几百个语音就可以了。 　　在合成的时候需要一张汉字对应拼音的对照表，汉字拼音输入法也依赖这张表，可以在网上找到，不过通常没有4声音调，大不了自己加上，呵呵，要不怎么说是力气活呢。 　　这样做出来的TTS效果也还可以，特别是朗读一些没有特别含义的如姓名，家庭住址，股票代码等汉语句子，听起来足够清晰。这要归功于我们伟大的母语通常都是单音节，从古代的时候开始，每个汉字就有一个词，表达一个意思。而且汉字不同于英语，英语里面很多连读，音调节奏变化很大，汉字就简单多了。 　　当然，你仍然要处理一些细节，比如多音字，把“银行”读成“yin xing”就不对了；再比如，标点符号的处理，数字、字母的处理，这些问题对于写过很多程序的你，当然不难了。 　　国内的一些语音板卡带的TTS，不管是卖钱的还是免费的，大体都是这样做出来的，也就是这样的效果。 　　如果要把TTS的效果弄好一点，再来点力气活，把基本的词录制成语音，如常见的两字词，四字成语等，再做个词库和语音库的对照表，每次需要合成时到词库里面找。这样以词为单位，比以字为单位，效果自然是好多了。当然，这里面还是有个技术，就是分词的技术，要把复杂的句子断成合理的词序列，也有点技术。这也要怪新文化那些先驱们，当初倡导白话文，引进西文的横排格式、标点符号的时候，没有引进西文中的空格分词。不过即使分词算法那么不高效，不那么准确，也问题不大，如前面所说，汉字是单音节词，把声音合起来，大体上不会有错。 　　当然，科大讯飞的力气活又干的多了些，据说已经进化到以常用句子为单位来录音了，大家可以想像，这要耗费更多的力气，换来更好的效果。 　　至于增加一些衔接处的“词料”，弄一些修饰性的音调，我认为是无关紧要的，对整体的效果改进不是太大。 　　市面上商品化TTS一般还支持粤语，请个粤语播音员录音，把上面的力气活重做一遍就是了。 　　再说句题外话，很多人觉得录音最好找电台、电视台的播音员，其实找个你周围的女同事来录制，只要吐字清晰就可以了。在某种情况下，寻常声音比字正腔圆的新闻联播来得可爱。 　　再来说说文本的标识，对于复杂文本，某些内容程序没有办法处理，需要标识出来。比如，单纯的数字“128”，是应该念成“一百二十八”还是“一二八”？解决办法通常是加入XML标注，如微软的TTS："<context ID = "number_cardinal">128</context>"念成“一百二十八”，"<context ID = "number_digit">128</context>"将念成“一二八”。TTS引擎可以去解释这些标注。遗憾的是，语音XML标注并没有形成大家都完全认可的标准，基本上是各自一套。 　　再说说TTS应用编程，微软的TTS编程接口叫SAPI，是COM接口，开发起来还是有点麻烦，还好MSDN的网站上资料很全面。微软的TTS虽然免费，但其中文角色目前是个男声，声音略嫌混浊，感觉不爽。 　　国内一般的厂家提供API调用接口，相对比较简单，可以方便地嵌入应用程序中去。 　　商品化的TTS还有个并发许可限制，就是限制同时合成的并发线程数，我觉得这个限制用处不大。无论哪种TTS，都可以将文本文件转换成语音文件，供语音卡播放。大部分应用句子比较短小，一般不会超过100个汉字，合成的时间是非常短的，弄个线程专门负责合成，其它应用向该线程请求就是了，万一句子很长，把它分解成多个短句子就是了，播放的速度总是比合成的速度慢。 　　也很多应用是脱机合成，没有实时性要求，就更不必买多个许可了。 　　更多情况下，我们甚至没有必要购买TTS，比如语音开发中常见的费用催缴，拨通后播放：“尊敬的客户，您本月的费用是：212元”，前面部分对所有客户都一样，录一个语音文件就是了，而数字的合成是很简单的，你只要录制好10个数字语音，再加上十，百，千，万，再加上金钱的单位“元”。 　　TTS(Training+Tool+Scheme)超越计划 　　针对目前成长型企业遇到的人力资源问题，立体化解决人力资源瓶颈、通过企业与专家共建、实现人才强企的人力资源方向的重大智业项目。为企业培养人力资源高级管理人才，提供先进人力资源管理工具，并协助企业建立现代人力资源战略规划。通过“培训（Training）+工具（Tool）+方案（Scheme）”的办法，为企业系统解决人力资源难点问题，进而搭建科学、完善的人力资源管理体系。 　　TTS TIANJIN TERMINAL SURCHARGE 　　天津港口附加费。09年从日韩经过的船所收的一个费用 答案来源网络，供参考，希望对您有帮助

最近，我问了我一个朋友他对"智能合约"的看法。他是一名开发者，我想他可能会有一些有趣的见解。令我惊讶的是，他并不知道智能合约是什么。我感到特别惊讶，因为我们讨论了一年多的加密货币、美国证券交易委员会（SEC）以及许多与区块链相关的其他事情。在计算机领域深耕的人怎么可能会不知道智能合约是什么？ 事实上，相比区块链行业的其它概念，智能合约可能会更令加密货币爱好者们感到困惑。因此，要解释这个概念并不容易，尤其是向那些刚刚理解区块链是什么的人解释更不容易。因此，这一概念依旧十分神秘。希望这篇文章可以清楚地解释好这一概念。 什么是智能合约？ 想象一下，如果你需要卖掉一栋房子，那么这将是一个复杂而艰巨的过程，不但需要处理大量的文书工作、与不同公司和人员进行沟通，而且还得冒着各类高风险。这就是为什么绝大多数房屋卖家决定寻找房地产经纪，来帮助处理所有文书工作、推销房产，并在协商开始时充当中介、监督交易直至交易结束。 此外，该经纪机构还提供委托付款服务，这在此类交易中尤其有用，因为此类交易所涉及的金额通常很大，你将无法完全信任将要与你进行交易的人。然而，在交易成功完成之后，卖方和买方的经纪机构将获得房产卖出价格的7%作为佣金。这对卖方来说是相当大的经济损失。 在这种情况下，智能合约就可以真正派上用场，可以有效地变革整个行业，同时也减少了所需流程。或许最重要的是，智能合约能解决信任问题。智能合约基于"If-Then"（"如果-那么"）原则，这意味着只有商定的金额被发送到系统时，房屋的所有权才会被转移给买方。 智能合约也可以作为委托付款服务，这意味着资金和所有权都将被存储在系统中，并在同一时间被分发给各参与方。此外，该交易被数百人见证和验证，因此保证了交付是无差错的。由于双方之间不再存在信任问题，因此也不再需要中介。所有房地产经纪能做的都可以预先编程为智能合约，这同时也为卖方和买方节省了大量资金。 这只是智能合约潜在用途的一个例子。智能合约能够帮助货币、财产和其他任何有价值的东西的交易，确保交易过程完全透明，其不但无需中介服务及其附带费用，还消除了双方之间的信任问题。特定智能合约的代码包括了各方商定的所有条款和条件，有关交易本身的信息则被记录在区块链中，即去中心化的分布式公共账本。 智能合约是如何运作的？ 简而言之，智能合约很像自动售货机。你只需将所需数量的加密货币放入智能合约中，而你所交易的，房屋所有权等就会自动存入你的账户。所有的规则和处罚不仅在智能合约预先定义了，而且也由智能合约强制执行。 相互依存 智能合约可以独立运行，但也可以与任何其他智能合约一起运行。当它们彼此依赖时，它们可以以某种方式被设置。例如，成功完成一个特定的智能合约可以触发另一个智能合约的启动，依此类推。从理论上讲，整个系统和组织完全可以依靠智能合约运行。某种程度上，这已经在各种加密货币系统中实现了，在这些系统中，所有的规则都是预先定义好的，因此，网络本身可以独立自主地运行。 智能合约的对象 从本质上讲，每个智能合约都有三个不可或缺的部分（也称为对象）。第一个对象是签署方（两方或多方使用智能合约，同意或不同意使用数字签名的协议条款）。 第二个对象是合约的主题。它只能是智能合约环境中存在的对象。或者，智能合约必须可以不受阻碍地直接访问该对象。尽管智能合约早在1996年就被讨论过，但正是这一特定对象阻碍了智能合约的发展。这个问题直到2009年出现第一个加密货币后才得到部分解决。 最后，任何智能合约都必须包含特定条款。这些条款都需要使用数学方法及适用于特定智能合约环境的编程语言进行完整描述。这些条款包括了所有参与方的预期要求以及与所述条款相关的所有规则、奖励与惩罚。 环境 为了使智能合约能够正常运行，智能合约必须在特定的合适环境中运行。首先，智能合约环境需要支持公钥加密，这使得用户能够使用其独特的、专门生成的加密代码来签署交易。这正是绝大多数现有加密货币所用的系统。 其次，它们需要一个开源和去中心化的数据库，合同各方都可以彼此完全信任，并且履约流程完全自动化。此外，为了实现智能合约，整个环境必须自身是去中心化的。区块链，尤其是以太坊区块链，是运行智能合约的理想环境。 最后，智能合约所使用的数据，来源必须完全可靠。这就需要使用根SSL安全证书、HTTPS和其他已经广泛被使用并在大多数现代软件上自动实现的安全连接协议。 智能合约带来了什么？ 自治 智能合约消除了对第三方中介的需求，基本上使你能够完全控制合约。 信任 任何人都无法窃取或弄丢你的文件，因为它们已被加密并安全地存储在一个安全的公开账本中。此外，你不必信任你正与之交易的人，也不必指望他们会信任你，因为公正的智能合约系统基本上解决了信任问题。 节约 由于使用了智能合约，你就不需要公证人、房地产经纪人、顾问及其他众多中介机构的援助。这样也就与他们的服务相关的高额费用无关了。 安全 如果智能合约正确执行，它将是极难破解的。此外，智能合约的完美环境受到复杂的加密保护，它可确保你文档的安全。 高效 通过使用智能合约，你将节省通常浪费在手动处理大量纸质文档并将其发送或运送到特定地点等的大量时间。 谁发明了智能合约？谁在使用智能合约？ 1996年，计算机科学家和密码学家Nick Szabo首次提出了智能合约。几年后，Szabo重新定义了这一概念并发布了几篇相关文章，他阐述了通过在互联网上陌生人之间设计的电子商务协议来建立合同法相关商业实践的概念。 然而，智能合约的概念直到2009年才被实现，当时第一个加密货币比特币连同它的区块链一齐出现，后者则最终为智能合约提供了合适的环境。有趣的是，Nick Szabo在1998年设计了一种称为比特黄金（Bit Gold）的去中心化数字货币。虽然它没有被实现，但它已经具备了10年后比特币可吹嘘的许多功能。 如今，智能合约主要与加密货币有关。而且，可以公平地说，它们彼此互相依赖，因为去中心化的加密货币协议本质上是具有去中心化安全性的加密智能合约。智能合约现在被广泛应用于大多数加密货币网络中，并且其也是以太坊最杰出和最被大肆宣传的特点之一。 你知道什么是智能合约吗？币圈聚贤庄来跟你分析一下！ 智能合约用例 虽然世界各国政府、金融监管机构和银行对加密货币的立场从极其谨慎变成谨慎接受，但加密货币背后的技术，区块链和智能合约，已被广泛认为是具有革命性的，并且正在各个层面实现这些技术。 例如，美国信托与清算公司（DTCC）和四大银行（美银美林、花旗、瑞士信贷和摩根大通）成功地使用Axoni开发的智能合约交易区块链信用违约掉期。智能合约使用了诸如个人交易详情及相应风险指标之类的信息，据一篇新闻稿称，这提高了合作伙伴和监管机构信息处理上的透明度。 类似的事情到处都在发生。由61家日本银行和韩国银行组成的财团一直在测试Ripple的区块链和智能合约，以实现两国之间的跨境资金转移。这一新系统将于今年推出。就连俄罗斯政府控制的俄罗斯联邦储蓄银行（Sberbank），都在俄罗斯这样一个众所周知的反加密货币国家测试以太坊区块链及其智能合约。 测试结果是俄罗斯联邦储蓄银行加入了以太坊企业联盟（EEA），这是一个由100多家企业组成的联盟，其中包括了思科、英国石油、荷兰国际集团（ING）、微软等顶级企业。该联盟旨在开发一种面向商业用途的区块链，用它可以开发和实现这些公司所需的智能合约。 由于智能合约是与加密货币相关联的，因此它们仍主要被应用到金融领域和银行业。尽管如此，世界各国政府都可以使用这项技术，使得投票系统更加便利而透明。供应链可以使用它来监控货物并自动执行所涉及的所有任务和支付。房地产、医疗保健、税收、保险及其他众多行业都可以受益于智能合约的使用。 智能合约的缺点 智能合约仍是一项未成熟的技术，仍然容易出现问题。例如，构成合约的代码必须是完美无漏洞的。它也会出现错误，有时候，这些错误会被欺诈者所利用。就像DAO被黑事件一样，把资金存放在代码有漏洞的智能合约中资金就可能被盗走。 此外，这项新奇的技术也带来了很多问题。政府将如何决定监管此类合约？他们将如何进行征税？如果合约无法访问其主题，或者发生了任何意外情况，将会是什么情况？这是在传统合约签订时可能发生的，传统合同可以在法庭上被撤销，但区块链要求智能合约无论如何都要按照"代码即法律"的规则去执行。 然而，大多数这些问题的存在纯粹是因为智能合约仍未是一项成熟的技术。但这项技术肯定会随着时间的推移而逐渐完善。毫无疑问，智能合约将会成为我们社会不可或缺的一部分。

【丁宁-清华大学-阿里达摩院自然语言技术实习体验】 作者简介：丁宁，清华大学计算机科学与技术系2年级博士生，研究方向为自然语言处理、信息抽取、语言表示学习等，在ACL、EMNLP、AAAI、IJCAI等发表多篇文章，作为研究型实习生在阿里达摩院实习半年+。 实习体会 很幸运能来到阿里巴巴进行实习！组里的氛围特别好，同事和师兄师姐都非常专业、友善、亲切。无论是科研上还是工作生活上的任 何问题，都能得到慷慨的帮助。在这里，我认识了一批学术和生活上的榜样（我的主管每天都吃健康餐，而我牛肉汤泡饼），结交了志同道合的朋友（排队喝牛肉汤回来写论文的日子），见识到了IT同学的认真负责（远程帮我调试打印机，周末修电脑），见过了马云老师，也亲身经历了一次双十一奋战。阿里的科研积淀和文化氛围都让我感到收获颇丰，感谢阿里巴巴提供研究型实习生这一高水平项目，也期待更多的同学可以加入研究型实习生的大家庭。 科研心得& 工作宣传 今年在阿里巴巴所做的跨领域分词工作被ACL 2020高分接收，其中meta review说“well-written, well-motivated with strong results, sure accept”。其实这句话可以很好地总结评判科研论文好坏的标准，实际上或许现阶段的科研也并没有什么秘密，动机明确、方法得当、实验充分，就可以形成一篇不错的科研论文。当然了，如果想做出让领域内眼前一亮的工作，可能就需要一些灵光一闪了。 具体到我们的工作上来，跨领域任务往往面临目标领域精标注数据缺失的问题，具体到分词任务上来说，这种数据缺失往往会导致OOV和词的分布差异问题。本文通过弱监督启发式算法来进行远程标注，并引入对抗学习来进行降噪。本文的实验中以newswire (新闻语料)作为源领域，在5个不同的目标领域数据上都取得了较好的效果。 这个工作或许有助于我们真正的往跨领域的两个通用问题上去设计了相关的解决办法。论文名字:《Coupling Distant Annotation and Adversarial Training for Cross-Domain Chinese Word Segmentation》，具体可以查看达摩院的官方宣传~：ACL 2020有哪些值得关注的论文？ - 阿里巴巴达摩院的回答 - 知乎https://www.zhihu.com/question/385259014/answer/1190808208 另外，也宣传一下作为co-author的另一篇ACL 2020论文，是实习生同事周洁（上海交大研究生）的工作，瞄准多层级文本分类任务，设计层级敏感编码器将多层结构作为有向图建模，并且实现了一个串行和并行的版本，论文名字：Hierarchy-Aware Global Model for Hierarchical Text Classification。 还有另一个实习生同事张浩宇（国防科大博士生）在IJCAI 2020的工作，使用noisy learning的方法去进行远程监督entity typing降噪，方法非常优雅，论文名字：Learning with Noise: Improving Distantly-Supervised Fine-grained Entity Typing via Automatic Relabeling。 【杜志浩-哈尔滨工业大学-我在达摩院作实习研究僧的那些事儿】 经韩老师介绍，2019年7月，有幸进入阿里巴巴达摩院成为一名实习研究僧。如今也已半年有余，期间发生的事情仍然历历在目。从初出茅庐的不安，到积极融入的快乐，再到宠辱不惊的泰然，一路走来收获良多! 初出茅庐 其实，刚到达摩院语音算法组时，我的内心充满了不安。这种不安来自于初出茅庐的不自信，不知自己能否胜任这份工作，为公司带来效益。同时，也来自于环境转变的不适应，换了一个全新的环境，对公司内的工作方式、待人接物都不甚了解。 但是，在算法组师兄师姐的帮助下，我的这些不安很快就烟消云散了。为了能够使我尽快熟悉工作内容、了解工作方式，雷鸣师兄坚持每周四晚上为实习生开组会，拉着仕良哥、智颖等很多小伙伴一起讨论算法思路和实验中遇到的问题。我想他们应该都挺忙的吧，但还是牺牲自己休息的时间来参加组会。 刚来的那段时间，除了“雷老师，xxx麻烦审批通过一下”以外，我说的最多的恐怕就是“xx姐/哥，xxx在哪”。由于对很多事情都不了解，比如服务器怎么申请啊，oss怎么弄啊，我总是要麻烦逍北姐、遥仙哥等目之所及的小伙伴。他们一边在忙自己的工作一边还不厌其烦的告诉我，为我提供了莫大的帮助。 积极融入 在算法组这段时间，让我印象最为深刻的一句话就是“我们做事情都很直接，有什么问题，就带着方案提出来”。以前，总是被教育和鼓励发现问题，在阿里，找到问题只是完成了第一步，还需要再提出一个切实可行的解决方案。期间发生的一段小插曲让我现在依然记忆犹新。  为了准备910，语音测试组的小伙伴每天都在紧张的进行测试。其中一项是对语音实时转录及翻译软件的稳定性测试。由于已经进入应用阶段，不能在直接将数据送入到模型中，需要将语音播放出来，再由软件录音进行测试。播放的内容是马老师的演讲，对于坐在旁边的小伙伴来说既是一件好事，也是一件坏事。由于马老师的演讲实在太引人入胜了，每次他们进行测试时，我们都无法专心工作，最终只能……。 咳咳，我心想，这么下去也不是事儿啊，梦想要有，生活也得继续啊，得想想办法解决一下这个问题。我尝试了各种办法，但似乎都无法绕过功放这个问题。最终功夫不负有心人，找到了一款虚拟声卡的软件，能够将一个应用程序的音频输出直接作为另一个应用程序的输入。在熟悉过这个软件的使用方式后，我找到测试组的组长，向他提出了我现在的处境和解决方案。他告诉我，他也知道这样会打扰到周边的人，但是之前也没有太好的办法，感谢我提出的解决方案。 虽然这只是实习期间的一段小插曲，但是我依然印象深刻。通过这件事，我践行了带着方案提问题，这一阿里人所特有的工作方式，让我感觉自己正在逐渐融入到这个集体当中。 宠辱不惊 经过几个月“死去”又“活来”的做实验、写论文，我跟雷鸣师兄合作的语音增强相关工作投稿到了ICASSP 2020。这是语音信号处理领域的顶级会议，在来阿里之前，我也投稿过一次，但不幸被拒。为了准备这篇文章，雷鸣师兄跟我保持着很高互动，了解实验进度，适时的进行指导。此外，还有仕良哥帮助我进行语音畸变的评估。 2020年1月25日这一天，是我国的传统节日，春节，同时也是ICASSP出结果的日子。在得知结果前，我的内心非常忐忑。但当得知接收的喜讯时，我反而没有想象中那么兴奋，没有想象中那么高兴。我的第一反应是看看审稿人的意见，看看我专家们对我文章的看法，还有哪些不足和需要改进的地方。 我想宠辱不惊的心态应该是我在阿里的一个重要收获吧，不以物喜不以己悲。尽力做好自己该做的事儿，结果自然水到渠成。 再说两句 在阿里的这段实习使我受益匪浅。这里有乐于助人、善解人意的师兄师姐，也有认真负责、要求严格的主管Leader；有弹性自由的工作时间，也有肝到深夜的满腔热情；有最新最热的研究成果，也有成熟稳定的应用软件。这里不像实验室的象牙塔，关注技术的同时，也更关注技术如何落地、如何应用到生活中去，最终如何造福亿万用户。 韩鹏-KAUST-青春没有我之阿里巴巴天猫精灵争夺赛被迫写的研究心得 竞选宣言： 在阿里实习摸了几个月的鱼，最开心的就是又吃到了祖国的美食，虽然杭州的食物实在是太清淡了，但总比我在沙特每天吃水煮青菜不放盐要好很多。在阿里的这几个月，让我看淡了很多，发现生命里比较重要的就是长在自己脑袋上的头发，不能太年轻就失去他们。女网红我是感觉自己这辈子没机会了，毕竟流量明星也不是靠推荐算法能捧红的，也就希望能够得到这次500块钱的天猫精灵，请大家pick我。 研究心得： 多抱大腿 为了凑足300字的内心情感白描： 这个世界实在是太无聊了，尤其疫情导致的只能居家办公，我已经憋得快精神失常了，虽然平时也不是那么正常。希望这个世界早日恢复原来的美好，我还打算去越南胡志明市的日式KTV感受一下女仆装呢，希望疫情不会让这些服务业倒闭呢吧。 居然还不够300字，感觉生命浪费在写文字上要比大保健上还是好一些的，希望这些文字能够启发你，虽然我感觉也并没有什么意义，而人活着的意义又是什么呢？ 【韩镕罄-南加州大学- 阿里研究型实习生体验】 简介： 经过两年研究时间，找到了学校的教职，也找到了老婆，感谢阿里～ 2018年八月来阿里做研究型实习生，本人在南加州大学商学院读Operations Management 的Ph.D. 块两年时间做了几篇 field experiment paper， 感觉阿里有太多好玩有趣的商业问题可以讨论直接研究。 通过和阿里的合作顺利找到UIUC 伊利诺伊大学香槟分校的常任轨教职。 更神奇的是，在实习期间，随便刷个阿里妹儿的相亲帖， 加个微信 聊一聊 发现和自己一天生日。 就是你了！现在已经结婚快半年！ 三十而立，一切静好，感谢阿里！ 【马腾-清华大学- 阿里巴巴RI项目心得】 我与阿里之缘 在2019年的夏天，后来成为我主管的文侑来到清华进行交流，当时的我刚刚完成了一个学术项目的研究，正在寻求于之后的研究方向。恰好在交流会上碰见了文侑，经过一番交流之后吗，了解到操作系统团队是阿里 RDMA 技术的先行者和推广者，这正是我计划之后想要研究的方向，于是便一拍即合。由于我之前所研究的领域刚好符合是阿里目前正在做的一些项目，所以文侑提供了一个可以在阿里实习的机会。 在通过了多轮面试之后，我终于成功的入职了操作系统内核组作为学术型实习生。从2018年九月初入职至今，将近两年的时间，我也逐渐地适应了在阿里的生活，松弛有度而又充满欢乐。在这里我也结识了许多要好的朋友，并且，通过公司组织的各种聚会和团建的活动，让我解释了许多有着共同语言爱好的伙伴，大家给与了我这个新人很多的帮助和照顾，使我也渐渐地融入了这个有爱的团队。 在阿里的学术成果 在阿里实习期间，在同事们的帮助下，我顺利地完成了两个与我所在实验室合作的学术项目，并且这两个项目也幸运的产出了两篇高质量的论文，分别发表在了不同领域的高水平会议当中。 其中，第一篇论文发表在第21届Cluster会议，与2019年在美国阿尔伯克基召开。Cluster 是高性能计算方向计算机系统领域的主要会议，这个工作提出并实现了统一高效的 RDMA 消息中间件，解决了 RDMA 在实际生产过程中的一些关键可靠性和可用性问题，例如：极简的接口抽象，必要的上层消息确认机制，中间件辅助流控配合 DCQCN，结合生产系统的诊断机制等等，目前该技术已经被广泛应用在阿里巴巴基础云产品中（包括：数据库，分布式存储等）。另外一个工作则发表在了第25届 ASPLOS会议。ASPLOS 是操作系统，体系结构和编程语言三个方向综合的计算机系统领域顶级会议。这篇论文是和我所在的清华高性能所合作完成的，文章中第一次提出了利用RDMA将数据中心的NVM做disaggregation, 实现了高效的框架，同时证明了这种新架构的可行性。 在阿里的感想 阿里巴巴操作系统团队是一直致力于建立和完善系统领域工业界和学术界的纽带，并且在持续实践工业界和学术界之间的问题分享和工作互动，他们希望通过这些分析和互动能够更好地促进中国在世界计算机系统领域的整体发展和创新。作为操作系统团队中的一员，我深切了解到了先进技术对于企业发展的重要性，在实习的过程中，同我所在的实验室进行合作，我更是深深感受到只有通过学术与工业相辅相成，才能够真正让企业发展先进技术。另外一方面，经过一段时间的实习，我对所在的操作系统团队和阿里技术部门的工作有了更深入的了解，我对自己也有了进一步的规划，计划在毕业之后能够入职阿里，通过我的努力，继续在追逐技术之路上奋斗着。 【亓家鑫-新加坡南洋理工大学- 阿里云实习心得】 非常荣幸我们的研究工作*《Two causal principles for improving visual dialog》*获得了同行的认可，并收录在CVPR 2020会议中。在此要特别感谢我的教授，MReaL实验室成员以及阿里城市大脑实验室师兄师姐一直以来的支持和帮助。比起论文本身的内容，我更希望跟大家分享一年来做研究的心得和感悟，虽然目前我仍然是一个萌新，不过我希望通过萌新的角度能带给大家一些研究上的启发。 开始一个研究之前，选择方向很重要。当然，每一个方向都有自己的优缺点，比如新的方向“容易”发文章，可能将其他领域原有的方法引入加一些调整就可以达到比较高的结果。不过如果没有坚实的创新，在同行评议时，可能会受到质疑。一旦没有通过，再转投时可能发现已经落后于其他人。“老“的方向可能会感觉灌水困难，不过因为我没有真正做过经典的方向，所以不太好发表评论。根据观察，在一堆全面而又坚实的研究中找到创新点，对萌新来说确实困难，不过一旦有所突破，肯定会对这个社区产生广泛的影响。作为一个萌新，可能不会自己选择方向或者领域，所以接受导师或者主管的安排成了唯一的选择，不过要相信自己的导师和主管，因为大家都是在帮助你，而且他们经验丰富。只有当自己走完一套研究的流程，并且真正找到自己感兴趣或者觉得可以有所突破的方向，那可能才是真正属于自己的研究的开始。 当选定了方向，开始做研究的时候，清楚的了解所有有关的方法是非常重要的，因为这样可以防止你的idea被存在的方法“抄袭“。其实对一个比较成熟的研究方向来说，简单思考得到的idea一般都会被提出过。不过研究完所有存在方法后，要跳出这些方法，因为阅读他们的方法可能不是来借鉴，更多的是防止撞车，想要真正有创新，在别人的方法上改动往往是不够的，这就要求我们重新审视这个任务甚至数据集的每一个样本。当然目前即使是学术界toy的数据集也有动辄几十万的数据量，看完是不可能的，不过根据自己的思路统计一些数据特征，有时候对研究会产生很大的帮助。当觉得自己已经掌握了这个数据集或者这个任务的时候，应该是跑一些baseline来练习了。 我作为萌新，没有从零开始写，而是找了一个现成的模型开始修改，这样难度会减少很多，不过毕竟是别人的代码，还是有很多不舒服的地方，所以等自己成熟了的时候，有空的时候，一定要从头写一遍。当然我也不知道什么时候有空。当我开始修改baseline的时候，此次的研究旅行就算是上路了，在接受导师的指引的同时也可以自己不断的尝试自己的想法，因为不知道什么是有用的。我作为萌新刚开始的感受是我觉得可能我想的都有用，那一定要去试一下，所以我也建议大家多试一下，说不定真的有用呢，反正电费不花自己的。当一个东西有用的时候，就可以来思考他为什么有用了，当你想好它为什么有用并且通过了广泛的测试，就到了跟大家分享成果的时候。 当然，一个有用的idea背后可能有无数个没用的idea，至于他们为什么没用，我觉得如果实在是有兴趣，可以研究一下，但是有时候会花大量的时间。举一个实际的例子，我在去年做visual dialog比赛，大概四月份就发现了一个有用的方法，之后也顺利的拿到了第一并且在此基础上进行探究和扩展发表了自己的成果。不过同时，当时有一个效果降低的操作一直困扰着我，直到六个月以后，当然这六个月中还做了其他的事情，我才发现了它真正的原因，并且最终变成了我文章中的一句话。举这个例子的目的是，研究没有效果的idea会对研究有所帮助，不过可能会收益较低。 研究成果的发表是一个很重要的过程，它可以给领域内的同行以启发，甚至可以影响本领域之外的人，所以有时候高度总结自己的思想是一件有用的事情。比如我所做的工作我认为进行高度总结之后可以得到一个启发是：对多模态任务来说不一定所有模态都是平等的，对模型来说所存在模态也不一定是影响结果的全部。除了对自己motivation的总结，应用细节以及结果展示也是非常重要的，因为我是萌新，怎样写出一篇文章的经验肯定是不足的，所以在此不再赘述。在发表完文章之后，“售后服务“也是非常重要的一点，这也是我的教授教我的很重要的理念。因为发表的内容不是刊登出来就结束了，而是你对社区贡献的开始，之后做研究可能会发现更好的实现，或者当时的理论没有讲清楚完善，这些都可以补充到自己的代码中，让大家更好的了解你的思路和工作，或许以后还能收获好评。 此外，实验室的成员就是自己研究道路上的引导者和伙伴，会对自己的研究产生各种各样至关重要的影响，大多时候大家都不会吝惜跟你讨论分享自己的观点，有时还会亲自帮助你解决问题，所以要记得经常参加团建和小集体聚会。不过也不能太依赖别人，每当遇到问题的时候，特别是技术性的问题，还是依靠自己解决的好，毕竟未来总会离开实验室，离开乐于帮助你的人。最后，保护好自己的头发，还是要早睡早起，调不出来的bug熬夜也调不出来，不work的idea可能真的不work，没有人保证炼出来的一定是金子，不要过分影响正常的作息，毕竟这不是百米赛跑，也不能算是马拉松，而是长久的起码好几年以上要坚持的事业。不过我作为萌新才刚刚起步，依然没有体会到最艰难的时刻，不过做好心理准备还是应该的，该来的总是会来的。最后的最后希望这些浅显的经验总结能够给大家带来一点儿帮助，谢谢大家的阅读。 【田冰川-南京大学- 在阿里网络团队实习两年是一种怎样的体验？】 简介： 大家好！我是田冰川，南京大学2016级直博生，导师为田臣老师，研究方向为计算机网络。2018年6月，我以研究型实习生的身份入职阿里巴巴基础设施事业部网络研究团队，实习期间主要从事网络验证相关的研究工作，即通过形式化方法与灰度测试，来降低网络变更中的潜在风险。 2018年既是网络研究团队刚刚组建的一年，也是研究型实习生在阿里刚刚起步的一年。这年春天，经我导师田臣老师介绍，我参加了研究型实习生面试，加入了网络研究团队。 来到团队后，我参加的第一个研究项目是“金睛”，用以保障复杂ACL变更的正确性。ACL即访问控制列表，网络中的ACL决定着流量的连通性。网络架构演化有时会伴随着对ACL的迁移，如何保证迁移前后网络连通性是等价的，是困扰架构与运营部门的一大难题，而金睛项目则是为该问题而生。项目落地以来，金睛系统多次在骨干网ACL迁移中对变更方案进行了验证，并逐渐扩展至对边缘网络的验证。相关论文发表于SIGCOMM 2019主会，我在会场进行了20余分钟的演讲，与我们团队的另一篇文章HPCC共同成为阿里集团在网络领域top1学术会议主会中的首次亮相。 时间总是过的很快。转眼间，我来阿里已经两年了，自金睛之后，又陆续参与了多个研究课题。在阿里的时间越久，就越能切身体会到学术界研究与工业界研究的不同。在阿里实习以来，我接触到的所有研究课题，都不是凭空“想”出来的空中楼阁，更不是靠别人论文“启发”出来的二手课题，而是源自于真实业务的现阶段瓶颈与下一阶段发展趋势——这一点是高校科研很难做到的。 这两年间，我对科研这件事的心态也发生了进一步的变化。2017年，来到阿里之前，我的论文达到了学校博士毕业的最低要求，相当于没有了毕业之忧，对科研的心态从“先拿到博士学位再说”，变成了“想要做出点什么，不想让自己的博士5年就这么水过去”；在来到阿里，接触到工业界的前沿课题之后，我对科研的心态再一次发生了转变，变成“因为认可一件事的价值，所以想要去做好”——这已经成为一种内在的驱动力，让我在认真工作的同时，享受研究带来的乐趣。 如果一切顺利的话，我将于2021年6月博士毕业。能在阿里巴巴度过专属实习生的“三年醇”，想必也是人生中的一大成就了！ 【吴秉哲-北京大学- 吴师傅的博士研究课题：大数据时代的数据隐私研究方向初探】 加上本科的时间，不知不觉已经在燕园里面呆了八年了，明年不出意外应该就会离开学校去业界工作。准备最近以文章的形式梳理一下博士几年的研究以及生活的心路历程。由于内容比较分散，所以决定分为几个不同的部分。这次推送封面图片是16年骑行到加乌拉山口遥看喜马拉雅山脉的图片，而我在阿里的花名是风远，意为远处的风。希望多年之后，还有一颗少年的心，投入每天永不变。这次借着阿里内部一个活动的机会，写了今天的这篇稿子，为大家介绍一下我的thesis topic。 已经在蚂蚁实习了一年了，一年时光匆匆而过，而在蚂蚁金服度过的这段时光带给了我很多研究以及生活中的体验，这一年里学到的经验也将伴随着我之后的研究之路。 我本科四年是在数院度过，在研究生阶段决定转换方向到计算机系。博士的前两年一直在跌跌撞撞地寻找自己的研究方向，尝试过很多方向均以失败告终。终于在第三年的时候，误打误撞开始研究起机器学习的隐私保护问题并找到了很多灵感，开始沉淀了一些基本的研究工作。有一天我从一个朋友那里听到了她关于金服这边隐私保护机器学习的团队介绍，当时我就决定要到业界的前沿去看一看隐私保护的真实业界需求。在此之前，我已经在谷歌，IBM等公司有过多段实习的经历，但是在蚂蚁这一次实习经历，是与我自己研究方向最接近，也是时间最长的一次。借着这次约稿的机会，以此文简单总结一下自己过去两年在这一方向的研究。 隐私保护与共享学习 目前随着各种机器学习算法在集团的业务落地，许多隐私泄露与数据滥用的风险相继而来。 尤其是在蚂蚁金服这样一个拥有很多支付数据的企业，数据安全以及隐私保护的重要性更是不言而喻。站在商业合作的角度，如何实现不同公司或者部门之间的数据共享学习也是我所在的团队现在攻坚的一个问题。在这样一个研究背景下，我来到了蚂蚁金服的共享智能团队，开始和师兄师姐们从不同的维度对上述问题展开了深入的研究。 共享学习这样一个概念听起来很美好，但是实际落地起来却困难重重，需要考虑到上层软件算法的设计以及底层系统和硬件的优化，才有可能真正在实际的业务中兼顾效率和隐私保护强度。共享智能团队在这一方向上有着得天独厚的优势。一是领先的业务场景，在国际同行好多还停留在学术研究阶段时，我们团队已经和国内多家银行有了合作。另一个则是技术沉淀的领先。因为金服自身业务的特殊性，我们团队很早就开始了隐私保护机器学习和共享学习的布局，包括很多原始的技术沉淀，强大的工程团队以及学术预研团队。这些积累也使得我们能够很快地摸清最新的一些研究成果并能将其吸入到我们自己的系统当中。 我自己关于隐私保护机器学习的研究主要是围绕着三个层面展开，分别是理论，算法设计，以及系统和硬件优化。在理论层面，我主要针对现有的各种机器学习算法，建立相应的隐私泄露分析框架，比如我们在之前的工作中，针对一种常用的贝叶斯学习的算法根据雷尼差分隐私建立了隐私泄露的定量分析框架，我们进一步使用我们的框架和已有的一些泛化误差上界做了联系，从而能从多个角度去解释该算法的隐私泄露原因。在算法设计层面，我们针对各种已有的新兴算法以及场景，比如图神经网络，推荐系统建立了相应的共享学习算法，并利用我们的理论框架，对这些算法的隐私保护强度做了定量的评估。除开上层的理论和算法设计，底层的系统和硬件的优化同样是非常重要的一环。 在我们团队，我们主打基于硬件可信执行环境 (TEE)的机器学习serving系统，我针对我们当前这套服务系统，结合神经网络计算的一些特点，定制了该系统的一系列优化措施大大提升了整个系统的吞吐量。我也将其中一些措施注册了专利，并在前几天得到了内部的专利授权。除开上述介绍的学术研究方面的成果，我也参与了IEEE共享学习标准的制定会议，这也使得我从标准制定者的角度去更深地思考如何使用技术在未来社会中实现隐私与效率的兼顾。 总之，我自己很感谢能成为共享智能团队的一员，我在这里学到的最宝贵的经验就是详细地从上到下了解了这样一个大团队的合作与分工，学习他们是如何一步步从最初的需求分析，算法设计，到最后真正的业务落地。也很高兴和各位共享智能的同事度过自己博士生涯中很重要的一年。也非常感谢我的博士导师对我研究的无条件支持。回看博士这一路的艰辛，也是感慨万千。有点像自己之前高原骑行的经历，经历了爬到坡顶的缺氧与无力，终在转角处遇见了骑行途中最美的雪山风光。

在1024*768或者800*600的分辨率下可以自动调整成适用于该客户端分辨率的大小。 第一种方法：做一个网页解决问题（长了点） 如果只是因为浏览者改变了浏览器的设置，或者因为浏览器不兼容，使自己精心制作的网页变得"面目全非"，那多令人沮丧！下面我们以网页爱好者的常用工具Dreamweaver（以下简称DW）为例，列出几个网页制作初学者较常见的网页布局问题以及解决方法，希望对初学者们有所帮助。 一、消除任意缩放浏览器窗口对网页的影响 一番辛苦做出来的网页，在全屏状态下浏览一切正常。但在改变浏览窗口大小之后，网页就变得"不堪入目"了，这是个很值得注意的问题。 问题的根源还得从网页的布局说起，在DW中，网页内容的定位一般是通过表格来实现的，解决表格的问题也就成功了大半。 大家应该注意到，在DW中表格属性面板的高宽设定选择上提供了两种不同类型：百分比和像素值。百分比的使用将会产生前面说到的那个毛病。这里所说的百分比是指表格的高或宽设置为上层标记所占区域高或宽的百分比，如在一个表格单元的宽度是600，在它里面嵌入了另外一个表格，表格宽度占表格单元的50%，则这个表格的宽度为300，依此类推，如果在一个表格不是嵌于另一个表格单元中，则其百分比是相对于当时窗口的宽度的。IE浏览器中，随便改动主页窗口的大小时，表格的内容也随之错位、变形，就是因为表格的百分比也要随着窗口的大小而改变成相应的百分比宽度。 自然，解决这个问题的办法就是将表格宽度设置成固定宽度（也就是像素值）。另外如果外层表格已做好固定宽度设置，内层表格也可以适当使用百分比设置。清楚这个原则以后，如果出现类似的问题大家也知道怎么解决。 二、让网页居中 说到了窗口大小就会顺着路子想到分辨率的问题，在800×600分辨率下制作的网页在1024×768分辨率的机器上打开，整个网页就会跑到左边；1024×768分辨率的网页在800×600分辨率的机器上有时也会变得"不堪入目"。两种分辨率各做一个吧？做起来费时，看起来也费劲。怎么办呢？ 现在大多数网民都还在用800*600的分辨率，所以我们一般可以以此分辨率为主，要想让网页在1024*768时居中，只要在网页原代码的<body>后紧加一句<center>，</body>前加一句</center>就OK了。不过有几个问题这是要注意一下，第一个就是上面说到的百分比的问题，表格、单元格的宽度单位最好要使用像素单位，而不要用百分比。例如width=770。如果你的表格宽度设的是百分比，那么使用大于800×600的像素时，网页就会拉宽，这样网页可能会变形。在<body>中加入leftmargin=0，即<body leftmargin=0>这种情况下，800×600支持的表格宽度为780像素时不会出现滚动条。还有一点要注意的是不能用DW中的层来定位。 以下是引用片段： <html> <head></head> <body topmargin=0 leftmargin=0> <center> <table cellspacing cellpadding width=760><tr><td></td></tr></table> </center> </body> </html> 三、定义固定大小的文字 大家都知道,在IE浏览器的功能设置中，有一个可以自由设置窗口内容字体大小的功能，这样由于不同访问者的设置习惯不同，呈现在他们面前的网页有时也会不不相同。比如你可能本来设计时用的是2号字体，结果由于用户对浏览器的额外设定，变的更大了，这时你的网页也可能变得"不堪入目"。虽然不是你的错，但客户是上帝。 如果使用了网页中的CSS样式表技术，就不会出现上述情况了。使用快捷键"Shift+F11"打开样式表"CSS style"编辑器，在窗口中单击鼠标右键执行"New CSS style..."命令新建一个样式表，然后在给出的列表中选择"类型"选项，定义文字属性参数（一般文字的大小选择12px较为适宜）。完成后选择网页编辑窗中的文本，单击新的样式表名称，可以看到选中的文本发生了变化。预览时试试定义的文本字体尺寸还会不会随浏览器的选择字体大小而改变。 四、让网页适应不同的浏览器 浏览器的格局现在是两分天下，一分是IE，另一分是NetScape，在国内Ie有绝对的占有率，在这种情况下我们设计的网页只要兼容它就行了，但NetScape在国外还是有很多人使用，毕竟它是浏览器的元老。 虽然没有办法做出让所有浏览器都兼容的网站，但只要注意以下几点，做出来的网页在各个浏览器都中能达到比较好的显示效果： 不要混合使用层和表格排版，如果是父子关系，如层中表格，不在此原则范围内。 内联式的 CSS 在 Netscape Navigator 中经常会出现问题，使用链式或内嵌式。 有时需要在空层插入表格或者透明图片，以保证在 Netscape Navigator 里的效果。 对于只有几个像素宽度或高度的层，改用图片来实现。 避免使用 W3C 组织不推荐的排版属性，用 CSS 代替。 第二种方法：做两个适合不同分辨率的页面，一个是800×600，一个是1024×768，在800×600的页面中加入一下代码就可以实现跳转了： 解决分辨率问题在Dreamweaver中没有此项功能，我们只能手动加入一段Javascript代码。首先在change－ie.html或change－nc.html页面代码中的< head>和< /head>中加入以下代码： 以下是引用片段： < script language=JavaScript> < !－－ function redirectPage(){ var url800x600=〃index－ie.html〃; //定义两个页面，此处假设index－ex.html和1024－ie.html同change－ie.html在同一个目录下 var url1024x768=〃1024－ie.html〃; if ((screen.width==800) ＆＆ (screen.height==600)) //在此处添加screen.width、screen.height的值可以检测更多的分辨率 window.location.href= url800x600; else if ((screen.width==1024) ＆＆ (screen.height==768)) window.location.href=url1024x768; else window.location.href=url800x600; } // －－> < /script> 然后再在< body…>内加入onLoad=〃redirectPage()〃 最后，同样地，在< body>和< /body>之间加入以下代码来显示网页的工作信息： 以下是引用片段： < script language=JavaScript> < !－－ var w=screen.width var h=screen.height document.write(〃系统已检测到您的分辨率为:〃); document.write(〃< font size=3 color=red>〃); document.write(w＋〃×〃＋h); document.write(〃< /font>〃); document.write(〃正在进入页面转换,请稍候…〃); // －－> < /script> 答案来源网络，供参考，希望对您有帮助

1、拼多多被黑产薅羊毛事件 提名理由： 2019 年 1 月 20 日，微博爆料称拼多多出现重大 Bug：从网友晒出的图片看，此次 100 元无门槛券随便领，全场通用（特殊商品除外），有效期一年。有网友表示，凌晨 3 点多被同行“喊醒”，让来拼多多“薅羊毛”，“只需支付 4 毛钱，就可以充值 100 元话费”。 拼多多回应表示：有黑灰产团伙通过一个过期的优惠券漏洞盗取数千万元平台优惠券，进行不正当牟利。针对此行为，平台已第一时间修复漏洞，并正对涉事订单进行溯源追踪。同时我们已向公安机关报案，并将积极配合相关部门对涉事黑灰产团伙予以打击。 **翻车点评：**本次事件除了反映出拼多多在研发流程上的管控问题，也侧写出了中国企业的公关之难：在拼多多公关看来，此次被薅羊毛 200 亿的谣言是有心人在造谣抹黑；在旁观者看来，此次 200 亿谣言是拼多多的营销手段。一场罗生门背后，除了要敬畏每一行代码，还要敬畏每一位用户才是。 翻车等级：★★★☆☆ 2、苹果误发 7 倍工资给开发者，随后追回 提名理由： 2019 年 9 月 4 日，一位名为 @waylybaye 的 IOS 开发者在社交平台上爆料：“苹果搞了个大事故！！给国内开发者打上上个月的钱的时候，把单位是人民币的钱当成美元打过来了！所有开发者的收入都翻了 7 倍！现在这笔 7 倍的外汇已经到账可以申报了，但我不敢动……请问这种情况怎么搞？” 9 月 5 日，苹果官方发出邮件回应结算出错。在邮件中，苹果公司称，由于合作银行德意志银行方的问题，影响了开发者 2019 年 7 月的收入。希望开发者能够配合银行退回错误的金额，另外再汇一笔正确的金额。 该开发者表示将配合苹果公司退回款项，律师表示如果主张返还的行为给中国开发者带来很大的不便，甚至造成一些损失并有证据证明，那么中国开发者可以向苹果公司主张赔偿损失。 **翻车点评：**如果是越南开发者，收入岂不是翻了 2 万多倍？如果是津巴布韦开发者，岂不是要上天？ **翻车等级：**★★★☆☆ 3、李世石击败围棋 AI：怀疑电脑质量有问题 提名理由： 李世石是当今世界唯一一位曾经打败 AI 围棋程序 AlphaGo 的人类棋手，他在 2019 年宣布了正式退役。这位棋手表示：在 AI 出现之后，他意识到即使通过疯狂的努力再次成为排名第一的棋手，他也无法真正一览众山小，因为有一个实体你无法击败它。 此次退役赛，李世石选择了对战 NHN Entertainment 开发的 AI 围棋程序 HanDol，这名 AI 棋手已经打败了韩国排名前五的棋手。2019 年 12 月 18 日，退役赛首战，李世石被让两子，做好了首战告负心理准备的李世石却意外取胜，原因在于 AI 程序在对弈中出现了一个低级失误，被李世石抓住机会一举奠定胜局。赢棋后的李世石并没有表现出过多的兴奋，他甚至怀疑是这台电脑的质量没有达到应有的水平。 **翻车点评：**AI、大数据、云计算的三位一体 ABC 战略，将给未来的世界带来怎样的颠覆？也许再过几年，你看到的金翻车奖就是 AI 评选的了。 翻车等级：★★★☆☆ 4、程序员用 Null 做车牌，命中车管所漏洞吃下所有无主罚单 提名理由： Joseph Tartaro 是一位美国软件安全领域的专家，2016 年年底，Tartaro 决定要注册一块有个性的车牌。作为一名软件安全方面的专家，他有着许多技术人独有的职业癖好：希望车牌号能够与工作联系在一起。“我可以给我老婆注册一块 VOID 车牌，这样我们的车道就变成了 NULL 和 VOID 了”。 当然，这里面是有其深层含义的。Tartaro 在最近的一次 Defcon 黑客大会上说，“null”在很多编程语言中是一个文本字符串，用来表示空值或未定义的值。在很多计算机中，null 就是 void。也就是说，他跟她老婆其实是二位一体的存在，公不离婆秤不离砣，颇有点程序员式的浪漫。但很快，这个车牌就让他浪不起来了，因为 Null 命中了车管所系统漏洞，他为此收到了所有的无名罚单，总额超过 1.2 万美元。他后来坦言，初衷其实只是为了使用 Null 车牌来逃避罚单，万万没想到无名罚单却成了自己的。 延展阅读：使用 Null 做自定义车牌，成功命中车管所系统漏洞，所有未填车牌的罚单都是我的了 **翻车点评：**我在看房的时候是坚决不看 404 号门牌的，这哥们却主动给自己报空指针，果然跟那些妖艳贱货有些不同。 **翻车等级：**★★★☆☆ 5、游戏公司主程锁死服务器事件 提名理由： 2019 年 1 月 21 日，一封《告游戏行业全体同仁书》将一家创业公司 C++ 主程燕某推向舆论高潮，这篇文章指责燕某在就职深圳螃蟹网络科技有限公司 3 个月期间，出于报复心理，于游戏上线测试当天无故失踪并锁死电脑和服务器，最终导致公司开发两年的项目失败，损失惨重，创始人尹某背上百万债务开始打工之路。 1 月 24 日，燕某发表长文针对深圳市螃蟹网络科技有限公司创始人尹某的《告游戏行业全体同仁书》中提及的各项指责以及网络传言一一反驳，并表示一切法庭上见，相信法律会还一个公道。 **翻车点评：**2019 年让吃瓜群众真正学到了新闻等等再看，本次事件是典型的反转案例，从《告游戏行业全体同仁书》发布后的”程序员是如何逼死一家公司“的舆论，到后来的风向大反转，深刻地揭示了：瓜，要慢慢吃。脸，要慢慢打。 **翻车等级：**★★★★☆ 6、李彦宏被泼水 提名理由： 2019 年 7 月 3 日，百度 AI 开发者大会于北京国家会议中心举行。百度创始人、董事长兼任 CEO 李彦宏首先发表演讲。而在他正在演示 AI 自主泊车“最后一公里”时，有持矿泉水瓶的男青年冲上台，将水浇在李彦宏头上。李彦宏的白衬衫几乎湿透，他愣了一下后说：“What‘s your problem？” 随后泼水者被工作人员控制，李彦宏在掌声鼓励中说道：“大家看到在 AI 前进的道路上还是会有各种各样想不到的事情会发生。但是我们前行的决心不会改变，我们坚信 AI 会改变每一个人的生活。” **翻车点评：**在技术发展的历史上，总会出现风口过热的情况，无论是 AI 还是区块链，都存在被吹过头的现象，我们愿意看到有清醒的人为这些过热的技术降降温，但却绝对不认可目前这种方式。 翻车等级：★★★★☆ 7、62 岁程序员骚操作，翻车获刑 **提名理由： ** 现年 62 岁的大卫·廷利 (David Tinley) 来自匹兹堡附近的哈里森市，廷利为西门子在 Monroeville 的办事处工作了将近 10 年的时间，他曾接过一个为西门子公司创建管理订单的电子表格需求，电子表格包含自定义脚本，可以根据存储在其他远程文档中的当前订单更新文件的内容，从而允许公司自动化库存和订单管理。 廷利十年前在给西门子写的电子表格中植入了逻辑炸弹，它会在特定日期之后导致电子表格崩溃，于是西门子就必须再次雇佣他进行修复，每次都需要重新支付修复费用，持续时间近 3 年。最近他被抓包了，面临最高十年监禁和 25 万美元（约合人民币 172 万）的指控。 **翻车点评：**西门子居然没有人 review 代码，廷利居然忘了自己挖的坑的发作时间，60 多岁还没退休，资本主义果然罪恶，emmm… 翻车等级：★★★★☆ 8、FBI 网站被黑，数千特工信息泄露 提名理由： 在传统的好莱坞大片里，FBI 通常都是神通广大，无所不能，个个有着汤姆斯克鲁斯的脸，施瓦辛格的体格，既有拳脚功夫了得的特工，也有技术实力超群的 Nerd。从来只有他们攻破某某国家防火墙的份，但现实告诉我们，这真的只是在拍戏。 2019 年 4 月，包括 TechCrunch 等多家媒体报导，一个黑客组织黑了美国联邦调查局 FBI 的附属网站，并泄露了数千名联邦特工和执法人员的个人信息。黑客攻击了与 FBI 培训学院 National Academy Association 相关的三个网站，利用其中存在的漏洞，下载了每个服务器上的内容。随后黑客将数据发布到他们自己的网站上，并提供下载。电子表格在删除重复数据后包含大约 4 000 条独特记录，包括 FBI 特工与其它执法人员的姓名、个人和政府电子邮件地址、职位、电话号码和邮政地址等信息。 **翻车点评：**有道是终日打雁，却被雁啄了眼睛。但对我们这一代看着 FBI Warning 长大的孩子来说，FBI 它算个球。 翻车等级：★★★★☆ 9、IT 圈的暴力裁员事件 提名理由： 2018 年的春天，堪称近年来最暖的春天。彼时人工智能领域风起云涌，AI 创业公司们纷纷高薪疯抢 AI 开发者，月薪动辄 10 万级别。人工智能的流行还未结束，一个名叫区块链的技术突然又火爆了起来，一时间，“凡人饮水处，皆言区块链”。那是程序员们最甜蜜的一段时间。 这一年的上半年，互联网公司们扎堆上市，蔚为壮观：哔哩哔哩、爱奇艺、美团、小米、拼多多、趣头条……上市后的互联网新兴巨头、独角兽公司为了攻城略地，开启了全面的整军备战：唯有技术、开发者，才是未来的决定因素，这是技术最好的时代。许多人都如此笃信。 一年后的 2019，一切变了：保安赶走身患绝症员工、统计时长裁员、251、1024 等事件频繁映入眼帘，从最开始的愤怒到最后来的无助，我们感同身受。当企业紧缩银根，高薪资的开发们就成了裁员者的 KPI 了。 **翻车点评：**2019 也许是过去十年最坏的一年，也可能是未来十年最好的一年。如果真到万不得已，我们只求一场好聚好散。PS：小编我买了一支录音笔。 **翻车等级：**★★★★★ 10、波音 737 Max 客机软件故障坠机事件 提名理由： 2019 年 3 月 10 日，埃塞俄比亚航空公司一架波音 737 MAX 8 客机在飞往肯尼亚途中坠毁。机上有 149 名乘客和 8 名机组成员，无人生还。据报道，此次失事的是一架全新的波音飞机，四个月前才交付给该航空公司。这是波音 737 MAX 8 半年内出现的第二起严重事故。（第一起为 2018 年 10 月 29 日印尼狮航的坠落事件，189 人罹难） 两次空难的影响因素都有该机型配置的自动控制下压机头的系统，其设计初衷是，如果机身上的传感器检测到高速失速的情况，即使在没有飞行员输入信号的情况下，该系统将强制将飞机的机头向下推。但在狮航空难事件中，该系统接收到了错误数据，导致飞机在正常情况下开始不断下压机头，飞行员在 11 分钟内连续手动拉升 20 余次终告失败，坠海罹难。 这次事故引发了技术圈的广泛讨论，这种由软件带来的自动化能力，究竟是好是坏？ **点评：**两起空难总计 346 条人命面前，我们不愿也不敢戏谑。通过对波音公司的陆续调查发现，该公司为了节省成本，裁员了大量资深开发，代之以时薪 9 美元的印度外包，这家数字化转型的“代表企业”看起来光鲜亮丽，但也有阳光下的阴暗背面。 **等级：**★★★★★ 其他候选事件 韩企被爆用免费饮料换 GitHub 上的 star Twitter CEO 杰克·多西的推特账号被黑 特斯拉 App 突然瘫痪，大批车主没法上车 太空作案，NASA 女航天员在太空盗窃前任银行账户 中国人霸榜 GitHub Trending 引发国外开发者不满 你心目中，今年的翻车新闻之首是谁呢？

Kafka 是目前主流的分布式消息引擎及流处理平台，经常用做企业的消息总线、实时数据管道，本文挑选了 Kafka 的几个核心话题，帮助大家快速掌握 Kafka，包括： Kafka 体系架构 Kafka 消息发送机制 Kafka 副本机制 Kafka 控制器 Kafka Rebalance 机制 因为涉及内容较多，本文尽量做到深入浅出，全面的介绍 Kafka 原理及核心组件，不怕你不懂 Kafka。 1. Kafka 快速入门 Kafka 是一个分布式消息引擎与流处理平台，经常用做企业的消息总线、实时数据管道，有的还把它当做存储系统来使用。早期 Kafka 的定位是一个高吞吐的分布式消息系统，目前则演变成了一个成熟的分布式消息引擎，以及流处理平台。 1.1 Kafka 体系架构 Kafka 的设计遵循生产者消费者模式，生产者发送消息到 broker 中某一个 topic 的具体分区里，消费者从一个或多个分区中拉取数据进行消费。拓扑图如下： 目前，Kafka 依靠 Zookeeper 做分布式协调服务，负责存储和管理 Kafka 集群中的元数据信息，包括集群中的 broker 信息、topic 信息、topic 的分区与副本信息等。 ** 1.2 Kafka 术语** 这里整理了 Kafka 的一些关键术语： Producer：生产者，消息产生和发送端。 Broker：Kafka 实例，多个 broker 组成一个 Kafka 集群，通常一台机器部署一个 Kafka 实例，一个实例挂了不影响其他实例。 Consumer：消费者，拉取消息进行消费。 一个 topic 可以让若干个消费者进行消费，若干个消费者组成一个 Consumer Group 即消费组，一条消息只能被消费组中一个 Consumer 消费。 Topic：主题，服务端消息的逻辑存储单元。一个 topic 通常包含若干个 Partition 分区。 Partition：topic 的分区，分布式存储在各个 broker 中， 实现发布与订阅的负载均衡。若干个分区可以被若干个 Consumer 同时消费，达到消费者高吞吐量。一个分区拥有多个副本（Replica），这是Kafka在可靠性和可用性方面的设计，后面会重点介绍。 message：消息，或称日志消息，是 Kafka 服务端实际存储的数据，每一条消息都由一个 key、一个 value 以及消息时间戳 timestamp 组成。 offset：偏移量，分区中的消息位置，由 Kafka 自身维护，Consumer 消费时也要保存一份 offset 以维护消费过的消息位置。 1.3 Kafka 作用与特点 Kafka 主要起到削峰填谷（缓冲）、系统解构以及冗余的作用，主要特点有： 高吞吐、低延时：这是 Kafka 显著的特点，Kafka 能够达到百万级的消息吞吐量，延迟可达毫秒级； 持久化存储：Kafka 的消息最终持久化保存在磁盘之上，提供了顺序读写以保证性能，并且通过 Kafka 的副本机制提高了数据可靠性。 分布式可扩展：Kafka 的数据是分布式存储在不同 broker 节点的，以 topic 组织数据并且按 partition 进行分布式存储，整体的扩展性都非常好。 高容错性：集群中任意一个 broker 节点宕机，Kafka 仍能对外提供服务。 2. Kafka 消息发送机制 Kafka 生产端发送消息的机制非常重要，这也是 Kafka 高吞吐的基础，生产端的基本流程如下图所示： 主要有以下方面的设计： 2.1 异步发送 Kafka 自从 0.8.2 版本就引入了新版本 Producer API，新版 Producer 完全是采用异步方式发送消息。生产端构建的 ProducerRecord 先是经过 keySerializer、valueSerializer 序列化后，再是经过 Partition 分区器处理，决定消息落到 topic 具体某个分区中，最后把消息发送到客户端的消息缓冲池 accumulator 中，交由一个叫作 Sender 的线程发送到 broker 端。 这里缓冲池 accumulator 的最大大小由参数 buffer.memory 控制，默认是 32M，当生产消息的速度过快导致 buffer 满了的时候，将阻塞 max.block.ms 时间，超时抛异常，所以 buffer 的大小可以根据实际的业务情况进行适当调整。 2.2 批量发送 发送到缓冲 buffer 中消息将会被分为一个一个的 batch，分批次的发送到 broker 端，批次大小由参数 batch.size 控制，默认16KB。这就意味着正常情况下消息会攒够 16KB 时才会批量发送到 broker 端，所以一般减小 batch 大小有利于降低消息延时，增加 batch 大小有利于提升吞吐量。 那么生成端消息是不是必须要达到一个 batch 大小时，才会批量发送到服务端呢？答案是否定的，Kafka 生产端提供了另一个重要参数 linger.ms，该参数控制了 batch 最大的空闲时间，超过该时间的 batch 也会被发送到 broker 端。 2.3 消息重试 此外，Kafka 生产端支持重试机制，对于某些原因导致消息发送失败的，比如网络抖动，开启重试后 Producer 会尝试再次发送消息。该功能由参数 retries 控制，参数含义代表重试次数，默认值为 0 表示不重试，建议设置大于 0 比如 3。 3. Kafka 副本机制 前面提及了 Kafka 分区副本（Replica）的概念，副本机制也称 Replication 机制是 Kafka 实现高可靠、高可用的基础。Kafka 中有 leader 和 follower 两类副本。 3.1 Kafka 副本作用 Kafka 默认只会给分区设置一个副本，由 broker 端参数 default.replication.factor 控制，默认值为 1，通常我们会修改该默认值，或者命令行创建 topic 时指定 replication-factor 参数，生产建议设置 3 副本。副本作用主要有两方面： 消息冗余存储，提高 Kafka 数据的可靠性； 提高 Kafka 服务的可用性，follower 副本能够在 leader 副本挂掉或者 broker 宕机的时候参与 leader 选举，继续对外提供读写服务。 3.2 关于读写分离 这里要说明的是 Kafka 并不支持读写分区，生产消费端所有的读写请求都是由 leader 副本处理的，follower 副本的主要工作就是从 leader 副本处异步拉取消息，进行消息数据的同步，并不对外提供读写服务。 Kafka 之所以这样设计，主要是为了保证读写一致性，因为副本同步是一个异步的过程，如果当 follower 副本还没完全和 leader 同步时，从 follower 副本读取数据可能会读不到最新的消息。 3.3 ISR 副本集合 Kafka 为了维护分区副本的同步，引入 ISR（In-Sync Replicas）副本集合的概念，ISR 是分区中正在与 leader 副本进行同步的 replica 列表，且必定包含 leader 副本。 ISR 列表是持久化在 Zookeeper 中的，任何在 ISR 列表中的副本都有资格参与 leader 选举。 ISR 列表是动态变化的，并不是所有的分区副本都在 ISR 列表中，哪些副本会被包含在 ISR 列表中呢？副本被包含在 ISR 列表中的条件是由参数 replica.lag.time.max.ms 控制的，参数含义是副本同步落后于 leader 的最大时间间隔，默认10s，意思就是说如果某一 follower 副本中的消息比 leader 延时超过10s，就会被从 ISR 中排除。Kafka 之所以这样设计，主要是为了减少消息丢失，只有与 leader 副本进行实时同步的 follower 副本才有资格参与 leader 选举，这里指相对实时。 3.4 Unclean leader 选举 既然 ISR 是动态变化的，所以 ISR 列表就有为空的时候，ISR 为空说明 leader 副本也“挂掉”了，此时 Kafka 就要重新选举出新的 leader。但 ISR 为空，怎么进行 leader 选举呢？ Kafka 把不在 ISR 列表中的存活副本称为“非同步副本”，这些副本中的消息远远落后于 leader，如果选举这种副本作为 leader 的话就可能造成数据丢失。Kafka broker 端提供了一个参数 unclean.leader.election.enable，用于控制是否允许非同步副本参与 leader 选举；如果开启，则当 ISR 为空时就会从这些副本中选举新的 leader，这个过程称为 Unclean leader 选举。 前面也提及了，如果开启 Unclean leader 选举，可能会造成数据丢失，但保证了始终有一个 leader 副本对外提供服务；如果禁用 Unclean leader 选举，就会避免数据丢失，但这时分区就会不可用。这就是典型的 CAP 理论，即一个系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）中的两个。所以在这个问题上，Kafka 赋予了我们选择 C 或 A 的权利。 我们可以根据实际的业务场景选择是否开启 Unclean leader选举，这里建议关闭 Unclean leader 选举，因为通常数据的一致性要比可用性重要的多。 4. Kafka 控制器 控制器（Controller）是 Kafka 的核心组件，它的主要作用是在 Zookeeper 的帮助下管理和协调整个 Kafka 集群。集群中任意一个 broker 都能充当控制器的角色，但在运行过程中，只能有一个 broker 成为控制器。 这里先介绍下 Zookeeper，因为控制器的产生依赖于 Zookeeper 的 ZNode 模型和 Watcher 机制。Zookeeper 的数据模型是类似 Unix 操作系统的 ZNode Tree 即 ZNode 树，ZNode 是 Zookeeper 中的数据节点，是 Zookeeper 存储数据的最小单元，每个 ZNode 可以保存数据，也可以挂载子节点，根节点是 /。基本的拓扑图如下： Zookeeper 有两类 ZNode 节点，分别是持久性节点和临时节点。持久性节点是指客户端与 Zookeeper 断开会话后，该节点依旧存在，直到执行删除操作才会清除节点。临时节点的生命周期是和客户端的会话绑定在一起，客户端与 Zookeeper 断开会话后，临时节点就会被自动删除。 Watcher 机制是 Zookeeper 非常重要的特性，它可以在 ZNode 节点上绑定监听事件，比如可以监听节点数据变更、节点删除、子节点状态变更等事件，通过这个事件机制，可以基于 ZooKeeper 实现分布式锁、集群管理等功能。 4.1 控制器选举 当集群中的任意 broker 启动时，都会尝试去 Zookeeper 中创建 /controller 节点，第一个成功创建 /controller 节点的 broker 则会被指定为控制器，其他 broker 则会监听该节点的变化。当运行中的控制器突然宕机或意外终止时，其他 broker 能够快速地感知到，然后再次尝试创建 /controller 节点，创建成功的 broker 会成为新的控制器。 4.2 控制器功能 前面我们也说了，控制器主要作用是管理和协调 Kafka 集群，那么 Kafka 控制器都做了哪些事情呢，具体如下： 主题管理：创建、删除 topic，以及增加 topic 分区等操作都是由控制器执行。 分区重分配：执行 Kafka 的 reassign 脚本对 topic 分区重分配的操作，也是由控制器实现。 Preferred leader 选举：这里有一个概念叫 Preferred replica 即优先副本，表示的是分配副本中的第一个副本。Preferred leader 选举就是指 Kafka 在某些情况下出现 leader 负载不均衡时，会选择 preferred 副本作为新 leader 的一种方案。这也是控制器的职责范围。 集群成员管理：控制器能够监控新 broker 的增加，broker 的主动关闭与被动宕机，进而做其他工作。这里也是利用前面所说的 Zookeeper 的 ZNode 模型和 Watcher 机制，控制器会监听 Zookeeper 中 /brokers/ids 下临时节点的变化。 数据服务：控制器上保存了最全的集群元数据信息，其他所有 broker 会定期接收控制器发来的元数据更新请求，从而更新其内存中的缓存数据。 从上面内容我们大概知道，控制器可以说是 Kafka 的心脏，管理和协调着整个 Kafka 集群，因此控制器自身的性能和稳定性就变得至关重要。 社区在这方面做了大量工作，特别是在 0.11 版本中对控制器进行了重构，其中最大的改进把控制器内部多线程的设计改成了单线程加事件队列的方案，消除了多线程的资源消耗和线程安全问题，另外一个改进是把之前同步操作 Zookeeper 改为了异步操作，消除了 Zookeeper 端的性能瓶颈，大大提升了控制器的稳定性。 5. Kafka 消费端 Rebalance 机制 前面介绍消费者术语时，提到了消费组的概念，一个 topic 可以让若干个消费者进行消费，若干个消费者组成一个 Consumer Group 即消费组 ，一条消息只能被消费组中的一个消费者进行消费。我们用下图表示Kafka的消费模型。 5.1 Rebalance 概念 就 Kafka 消费端而言，有一个难以避免的问题就是消费者的重平衡即 Rebalance。Rebalance 是让一个消费组的所有消费者就如何消费订阅 topic 的所有分区达成共识的过程，在 Rebalance 过程中，所有 Consumer 实例都会停止消费，等待 Rebalance 的完成。因为要停止消费等待重平衡完成，因此 Rebalance 会严重影响消费端的 TPS，是应当尽量避免的。 5.2 Rebalance 发生条件 关于何时会发生 Rebalance，总结起来有三种情况： 消费组的消费者成员数量发生变化 消费主题的数量发生变化 消费主题的分区数量发生变化 其中后两种情况一般是计划内的，比如为了提高消息吞吐量增加 topic 分区数，这些情况一般是不可避免的，后面我们会重点讨论如何避免因为组内消费者成员数发生变化导致的 Rebalance。 5.3 Kafka 协调器 在介绍如何避免 Rebalance 问题之前，先来认识下 Kafka 的协调器 Coordinator，和之前 Kafka 控制器类似，Coordinator 也是 Kafka 的核心组件。 主要有两类 Kafka 协调器： 组协调器（Group Coordinator） 消费者协调器（Consumer Coordinator） Kafka 为了更好的实现消费组成员管理、位移管理，以及 Rebalance 等，broker 服务端引入了组协调器（Group Coordinator），消费端引入了消费者协调器（Consumer Coordinator）。每个 broker 启动的时候，都会创建一个 GroupCoordinator 实例，负责消费组注册、消费者成员记录、offset 等元数据操作，这里也可以看出每个 broker 都有自己的 Coordinator 组件。另外，每个 Consumer 实例化时，同时会创建一个 ConsumerCoordinator 实例，负责消费组下各个消费者和服务端组协调器之前的通信。可以用下图表示协调器原理： 客户端的消费者协调器 Consumer Coordinator 和服务端的组协调器 Group Coordinator 会通过心跳不断保持通信。 5.4 如何避免消费组 Rebalance 接下来我们讨论下如何避免组内消费者成员发生变化导致的 Rebalance。组内成员发生变化无非就两种情况，一种是有新的消费者加入，通常是我们为了提高消费速度增加了消费者数量，比如增加了消费线程或者多部署了一份消费程序，这种情况可以认为是正常的；另一种是有消费者退出，这种情况多是和我们消费端代码有关，是我们要重点避免的。 正常情况下，每个消费者都会定期向组协调器 Group Coordinator 发送心跳，表明自己还在存活，如果消费者不能及时的发送心跳，组协调器会认为该消费者已经“死”了，就会导致消费者离组引发 Rebalance 问题。这里涉及两个消费端参数：session.timeout.ms 和 heartbeat.interval.ms，含义分别是组协调器认为消费组存活的期限，和消费者发送心跳的时间间隔，其中 heartbeat.interval.ms 默认值是3s，session.timeout.ms 在 0.10.1 版本之前默认 30s，之后默认 10s。另外，0.10.1 版本还有两个值得注意的地方： 从该版本开始，Kafka 维护了单独的心跳线程，之前版本中 Kafka 是使用业务主线程发送的心跳。 增加了一个重要的参数 max.poll.interval.ms，表示 Consumer 两次调用 poll 方法拉取数据的最大时间间隔，默认值 5min，对于那些忙于业务逻辑处理导致超过 max.poll.interval.ms 时间的消费者将会离开消费组，此时将发生一次 Rebalance。 此外，如果 Consumer 端频繁 FullGC 也可能会导致消费端长时间停顿，从而引发 Rebalance。因此，我们总结如何避免消费组 Rebalance 问题，主要从以下几方面入手： 合理配置 session.timeout.ms 和 heartbeat.interval.ms，建议 0.10.1 之前适当调大 session 超时时间尽量规避 Rebalance。 根据实际业务调整 max.poll.interval.ms，通常建议调大避免 Rebalance，但注意 0.10.1 版本之前没有该参数。 监控消费端的 GC 情况，避免由于频繁 FullGC 导致线程长时间停顿引发 Rebalance。 合理调整以上参数，可以减少生产环境中 Rebalance 发生的几率，提升 Consumer 端的 TPS 和稳定性。 6.总结 本文总结了 Kafka 体系架构、Kafka 消息发送机制、副本机制，Kafka 控制器、消费端 Rebalance 机制等各方面核心原理，通过本文的介绍，相信你已经对 Kafka 的内核知识有了一定的掌握，更多的 Kafka 原理实践后面有时间再介绍。