标量图错误如何解决

在开始谈我对架构本质的理解之前，先谈谈对今天技术沙龙主题的个人见解，千万级规模的网站感觉数量级是非常大的，对这个数量级我们战略上 要重 视 它 ， 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级？现在很流行的优步(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、 分布式系 统、数据结构和算法。

MongoDB ACID事务支持 这里要有一定的关系型数据库的事务的概念，不然不一定能理解的了这里说的事务概念。 下面说一说MongoDB的事务支持，这里可能会有疑惑，前面我们在介绍MongoDB时，说MongoDB是一个NoSQL数据库，不支持事务。这里又介绍MongoDB的事务。这里要说明一下MongoDB的事务支持跟关系型数据库的事务支持是两码事，如果你已经非常了解关系型数据库的事务，通过下面一副图对比MongoDB事务跟MySQL事务的不同之处。 MongoDB是如何实现事务的ACID？ 1）MongoDB对原子性（Atomicity）的支持 原子性在Mongodb中到底是一个什么概念呢？为什么说支持但又说Mongodb的原子性是单行/文档级原子性，这里提供了一个MongoDB更新语句样例，如下图： MongoDB是如何实现事务的ACID？ 更新“username”等于“tj.tang”的文档，更新salary、jobs、hours字段。这里对于这三个字段Mongodb在执行时要么都更新要么都不更新，这个概念在MySQL中可能你没有考虑过，但在MongoDB中由于文档可以嵌套子文档可以很复杂，所以Mongodb的原子性叫单行/文档级原子性。 对于关系型数据库的多行、多文档、多语句原子性目前Mongodb是不支持的，如下情况： MongoDB是如何实现事务的ACID？ MongoDB更新条件为工资小于50万的人都把工资调整为50万，这就会牵扯到多文档更新原子性。如果当更新到Frank这个文档时，出现宕机，服务器重启之后是无法像关系型数据库那样做到数据回滚的，也就是说处理这种多文档关系型数据库事务的支持，但MongoDB不支持。那么怎么解决Mongodb这个问题呢？可以通过建模，MongoDB不是范式而是反范式的设计，通过大表和小表可以把相关的数据放到同一个文档中去。然后通过一条语句来执行操作。 2）MongoDB对一致性（consistency）的支持 对于数据一致性来说，传统数据库（单机）跟分布式数据库（MongoDB）对于数据一致性是不太一样的，怎么理解呢？如下图： MongoDB是如何实现事务的ACID？ 对于传统型数据库来说，数据一致性主要是在单机上，单机的问题主要是数据进来时的规则检验，数据不能被破坏掉。而在分布式数据库上，因为他们都是多节点分布式的，我们讲的一致性往往就是讲的各个节点之间的数据是否一致。而MongoDB在这点上做的还是不错的，MongoDB支持强一致性或最终一致性（弱一致性），MongoDB的数据一致性也叫可调一致性，什么意思呢？如下图： MongoDB是如何实现事务的ACID？ MongoDB的可调一致性，也就是可以自由选择强一致性或最终一致性，如果你的应用场景是前台的方式可以选择强一致性，如果你的应用场景是后台的方式（如报表）可以选择弱一致性。 一致性 上面我们讲到了通过将数据冗余存储到不同的节点来保证数据安全和减轻负载，下面我们来看看这样做引发的一个问题：保证数据在多个节点间的一致性是非常困难的。在实际应用中我们会遇到很多困难，同步节点可能会故障，甚至会无法恢复，网络可能会有延迟或者丢包，网络原因导致集群中的机器被分隔成两个不能互通的子域等等。在NoSQL中，通常有两个层次的一致性：第一种是强一致性，既集群中的所有机器状态同步保持一致。第二种是最终一致性，既可以允许短暂的数据不一致，但数据最终会保持一致。我们先来讲一下，在分布式集群中，为什么最终一致性通常是更合理的选择，然后再来讨论两种一致性的具体实现结节。 关于CAP理论 为什么我们会考虑削弱数据的一致性呢？其实这背后有一个关于分布式系统的理论依据。这个理论最早被Eric Brewer提出，称为CAP理论，尔后Gilbert和Lynch对CAP进行了理论证明。这一理论首先把分布式系统中的三个特性进行了如下归纳： 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。 分区容忍性（P）：集群中的某些节点在无法联系后，集群整体是否还能继续进行服务。 而CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。 要保证数据强一致性，最简单的方法是令写操作在所有数据节点上都执行成功才能返回成功，也就是同步概念。而这时如果某个结点出现故障，那么写操作就成功不了了，需要一直等到这个节点恢复。也就是说，如果要保证强一致性，那么就无法提供7×24的高可用性。 而要保证可用性的话，就意味着节点在响应请求时，不用完全考虑整个集群中的数据是否一致。只需要以自己当前的状态进行请求响应。由于并不保证写操作在所有节点都写成功，这可能会导致各个节点的数据状态不一致。 CAP理论导致了最终一致性和强一致性两种选择。当然，事实上还有其它的选择，比如在Yahoo的PNUTS中，采用的就是松散的一致性和弱可用性结合的方法。但是我们讨论的NoSQL系统没有类似的实现，所以我们在后续不会对其进行讨论。 强一致性 强一致性的保证，要求所有数据节点对同一个key值在同一时刻有同样的value值。虽然实际上可能某些节点存储的值是不一样的，但是作为一个整体，当客户端发起对某个key的数据请求时，整个集群对这个key对应的数据会达成一致。下面就举例说明这种一致性是如何实现的。 假设在我们的集群中，一个数据会被备份到N个结点。这N个节点中的某一个可能会扮演协调器的作用。它会保证每一个数据写操作会在成功同步到W个节点后才向客户端返回成功。而当客户端读取数据时，需要至少R个节点返回同样的数据才能返回读操作成功。而NWR之间必须要满足下面关系：R＋W>N 下面举个实在的例子。比如我们设定N＝3（数据会备份到A、B、C三个结点）。比如值 employee30:salary 当前的值是20000，我们想将其修改为30000。我们设定W＝2，下面我们会对A、B、C三个节点发起写操作（employee30:salary, 30000），当A、B两个节点返回写成功后，协调器就会返回给客户端说写成功了。至于节点C，我们可以假设它从来没有收到这个写请求，他保存的依然是20000那个值。之后，当一个协调器执行一个对employee30:salary的读操作时，他还是会发三个请求给A、B、C三个节点： 如果设定R＝1，那么当C节点先返回了20000这个值时，那我们客户端实际得到了一个错误的值。 如果设定R＝2，则当协调器收到20000和30000两个值时，它会发现数据不太正确，并且会在收到第三个节点的30000的值后判断20000这个值是错误的。 所以如果要保证强一致性，在上面的应用场景中，我们需要设定R＝2，W＝2 如果写操作不能收到W个节点的成功返回，或者写操作不能得到R个一致的结果。那么协调器可能会在某个设定的过期时间之后向客户端返回操作失败，或者是等到系统慢慢调整到一致。这可能就导致系统暂时处于不可用状态。 对于R和W的不同设定，会导致系统在进行不同操作时需要不同数量的机器节点可用。比如你设定在所有备份节点上都写入才算写成功，既W＝N，那么只要有一个备份节点故障，写操作就失败了。一般设定是R＋W = N+1，这是保证强一致性的最小设定了。一些强一致性的系统设定W＝N，R＝1，这样就根本不用考虑各个节点数据可能不一致的情况了。 HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前，写操作是不会返回成功的。也就是说它的W＝N，而读操作只需要读到一个值即可，也就是说它R＝1。为了不至于让写操作太慢，对多个节点的写操作是并发异步进行的。在直到所有的节点都收到了新的数据后，会自动执行一个swap操作将新数据写入。这个操作是原子性和一致性的。保证了数据在所有节点有一致的值。 最终一致性 像Voldemort，Cassandra和Riak这些类Dynamo的系统，通常都允许用户按需要设置N，R，W三个值，即使是设置成W＋R<= N也是可以的。也就是说他允许用户在强一致性和最终一致性之间自由选择。而在用户选择了最终一致性，或者是W 3）MongoDB对隔离性（isolation）的支持 在关系型数据库中，SQL2定义了四种隔离级别，分别是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。但是很少有数据库厂商遵循这些标准，比如Oracle数据库就不支持READ UNCOMMITTED和REPEATABLE READ隔离级别。而MySQL支持这全部4种隔离级别。每一种级别都规定了一个事务中所做的修改，哪些在事务内核事务外是可见的，哪些是不可见的。为了尽可能减少事务间的影响，事务隔离级别越高安全性越好但是并发就越差；事务隔离级别越低，事务请求的锁越少，或者保持锁的时间就越短，这也就是为什么绝大多数数据库系统默认的事务隔离级别是RC。 下图展示了几家不同的数据库厂商的不同事物隔离级别。 MongoDB是如何实现事务的ACID？ MongoDB在3.2之前使用的是“读未提交”，这种情况下会出现“脏读”。但在MongoDB 3.2开始已经调整为“读已提交”。 下面说说每种隔离级别带来的问题： READ-UNCOMMITTED（读尚未提交的数据） 在这个级别，一个事务的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为“脏读（dirty read）”。这个级别会导致很多问题，从性能上来说，READ UNCOMMITTED不会比其他的级别好太多，但却缺乏其他级别的很多好处，除非真的有非常必要的理由，在实际应用中一般很少使用。 READ-COMMITTED（读已提交的数据） 在这个级别，能满足前面提到的隔离性的简单定义：一个事务开始时，只能“看见”已经提交的事务所做的修改。换句话说，一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫“不可重复读（non-repeatable read）”，因为两次执行同样的查询，可能会得到不一样的结果。 REPEATABLE-READ（可重复读） 在这个级别，保证了在同一个事务中多次读取统一记录的结果是一致的。MySQL默认使用这个级别。InnoDB和XtraDB存储引擎通过多版本并发控制MVCC（multiversion concurrency control）解决了“幻读”和“不可重复读”的问题。通过前面的学习我们知道RR级别总是读取事务开始那一刻的快照信息，也就是说这些数据数据库当前状态，这在一些对于数据的时效特别敏感的业务中，就很可能会出问题。 SERIALIZABLE（串行化） 在这个级别，它通过强制事务串行执行，避免了前面说的一系列问题。简单来说，SERIALIZABLE会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。实际应用中也很少在本地事务中使用SERIALIABLE隔离级别，主要应用在InnoDB存储引擎的分布式事务中。 4）MongoDB对持久性（durability）的支持 对于数据持久性来说，在传统数据库中（单机）的表现为服务器任何时候发生宕机都不需要担心数据丢失的问题，因为有方式可以把数据永久保存起来了。一般都是通过日志来保证数据的持久性。通过下图来看一下传统数据库跟MongoDB对于数据持久性各自所使用的方式。 MongoDB是如何实现事务的ACID？ 从上图可以看出，MongoDB同样是使用数据进来先写日志（日志刷盘的速度是非常快）然后在写入到数据库中的这种方式来保证数据的持久性，如果出现服务器宕机，当启动服务器时会从日志中读取数据。不同的是传统数据库这种方式叫做“WAL” Write-Ahead Logging（预写日志系统），而MongoDB叫做“journal”。此外MongoDB在数据持久性上这点可能做的更好，MongoDB的复制默认节点就是三节点以上的复制集群，当数据到达主节点之后会马上同步到从节点上去。

微服务 (MicroServices) 架构是当前互联网业界的一个技术热点，圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设，他们都有相同的疑问：一个微服务架构有哪些技术关注点 (technical concerns)？需要哪些基础框架或组件来支持微服务架构？这些框架或组件该如何选型？笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设，同时在这块也投入了很多时间去学习和研究，有一些经验和学习心得，可以和大家一起分享。 服务注册、发现、负载均衡和健康检查和单块 (Monolithic) 架构不同，微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构，服务之间通过轻量机制进行通信，这时候必然引入一个服务注册发现问题，也就是说服务提供方要注册通告服务地址，服务的调用方要能发现目标服务，同时服务提供方一般以集群方式提供服务，也就引入了负载均衡和健康检查问题。根据负载均衡 LB 所在位置的不同，目前主要的服务注册、发现和负载均衡方案有三种： 第一种是集中式 LB 方案，如下图 Fig 1，在服务消费者和服务提供者之间有一个独立的 LB，LB 通常是专门的硬件设备如 F5，或者基于软件如 LVS，HAproxy 等实现。LB 上有所有服务的地址映射表，通常由运维配置注册，当服务消费方调用某个目标服务时，它向 LB 发起请求，由 LB 以某种策略（比如 Round-Robin）做负载均衡后将请求转发到目标服务。LB 一般具备健康检查能力，能自动摘除不健康的服务实例。服务消费方如何发现 LB 呢？通常的做法是通过 DNS，运维人员为服务配置一个 DNS 域名，这个域名指向 LB。 Fig 1, 集中式 LB 方案 集中式 LB 方案实现简单，在 LB 上也容易做集中式的访问控制，这一方案目前还是业界主流。集中式 LB 的主要问题是单点问题，所有服务调用流量都经过 LB，当服务数量和调用量大的时候，LB 容易成为瓶颈，且一旦 LB 发生故障对整个系统的影响是灾难性的。另外，LB 在服务消费方和服务提供方之间增加了一跳 (hop)，有一定性能开销。 第二种是进程内 LB 方案，针对集中式 LB 的不足，进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头，该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案，下图 Fig 2 展示了这种方案的工作原理。这一方案需要一个服务注册表 (Service Registry) 配合支持服务自注册和自发现，服务提供方启动时，首先将服务地址注册到服务注册表（同时定期报心跳到服务注册表以表明服务的存活状态，相当于健康检查），服务消费方要访问某个服务时，它通过内置的 LB 组件向服务注册表查询（同时缓存并定期刷新）目标服务地址列表，然后以某种负载均衡策略选择一个目标服务地址，最后向目标服务发起请求。这一方案对服务注册表的可用性 (Availability) 要求很高，一般采用能满足高可用分布式一致的组件（例如 Zookeeper, Consul, Etcd 等）来实现。 Fig 2, 进程内 LB 方案 进程内 LB 方案是一种分布式方案，LB 和服务发现能力被分散到每一个服务消费者的进程内部，同时服务消费方和服务提供方之间是直接调用，没有额外开销，性能比较好。但是，该方案以客户库 (Client Library) 的方式集成到服务调用方进程里头，如果企业内有多种不同的语言栈，就要配合开发多种不同的客户端，有一定的研发和维护成本。另外，一旦客户端跟随服务调用方发布到生产环境中，后续如果要对客户库进行升级，势必要求服务调用方修改代码并重新发布，所以该方案的升级推广有不小的阻力。 进程内 LB 的案例是 Netflix 的开源服务框架，对应的组件分别是：Eureka 服务注册表，Karyon 服务端框架支持服务自注册和健康检查，Ribbon 客户端框架支持服务自发现和软路由。另外，阿里开源的服务框架 Dubbo 也是采用类似机制。 第三种是主机独立 LB 进程方案，该方案是针对第二种方案的不足而提出的一种折中方案，原理和第二种方案基本类似，不同之处是，他将 LB 和服务发现功能从进程内移出来，变成主机上的一个独立进程，主机上的一个或者多个服务要访问目标服务时，他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡，见下图 Fig 3。 Fig 3 主机独立 LB 进程方案 该方案也是一种分布式方案，没有单点问题，一个 LB 进程挂了只影响该主机上的服务调用方，服务调用方和 LB 之间是进程内调用，性能好，同时，该方案还简化了服务调用方，不需要为不同语言开发客户库，LB 的升级不需要服务调用方改代码。该方案的不足是部署较复杂，环节多，出错调试排查问题不方便。 该方案的典型案例是 Airbnb 的 SmartStack 服务发现框架，对应组件分别是：Zookeeper 作为服务注册表，Nerve 独立进程负责服务注册和健康检查，Synapse/HAproxy 独立进程负责服务发现和负载均衡。Google 最新推出的基于容器的 PaaS 平台 Kubernetes，其内部服务发现采用类似的机制。 服务前端路由微服务除了内部相互之间调用和通信之外，最终要以某种方式暴露出去，才能让外界系统（例如客户的浏览器、移动设备等等）访问到，这就涉及服务的前端路由，对应的组件是服务网关 (Service Gateway)，见图 Fig 4，网关是连接企业内部和外部系统的一道门，有如下关键作用： 服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，但是外部系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关可以集中做容错，保持外部良好的用户体验。监控，网关可以集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。日志，网关可以收集所有的访问日志，进入后台系统做进一步分析。 Fig 4, 服务网关 除以上基本能力外，网关还可以实现线上引流，线上压测，线上调试 (Surgical debugging)，金丝雀测试 (Canary Testing)，数据中心双活 (Active-Active HA) 等高级功能。 网关通常工作在 7 层，有一定的计算逻辑，一般以集群方式部署，前置 LB 进行负载均衡。 开源的网关组件有 Netflix 的 Zuul，特点是动态可热部署的过滤器 (filter) 机制，其它如 HAproxy，Nginx 等都可以扩展作为网关使用。 在介绍过服务注册表和网关等组件之后，我们可以通过一个简化的微服务架构图 (Fig 5) 来更加直观地展示整个微服务体系内的服务注册发现和路由机制，该图假定采用进程内 LB 服务发现和负载均衡机制。在下图 Fig 5 的微服务架构中，服务简化为两层，后端通用服务（也称中间层服务 Middle Tier Service）和前端服务（也称边缘服务 Edge Service，前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备，如 PC，Pad 或者 Phone）。后端服务启动时会将地址信息注册到服务注册表，前端服务通过查询服务注册表就可以发现然后调用后端服务；前端服务启动时也会将地址信息注册到服务注册表，这样网关通过查询服务注册表就可以将请求路由到目标前端服务，这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看，网关类似 Proxy 代理或者 Façade 门面模式，而服务注册表和服务自注册自发现类似 IoC 依赖注入模式，微服务可以理解为基于网关代理和注册表 IoC 构建的分布式系统。 Fig 5, 简化的微服务架构图 服务容错当企业微服务化以后，服务之间会有错综复杂的依赖关系，例如，一个前端请求一般会依赖于多个后端服务，技术上称为 1 -> N 扇出 (见图 Fig 6)。在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源 (线程，队列等) 被耗尽，造成所谓的雪崩效应 (Cascading Failure，见图 Fig 7)，严重时可致整个网站瘫痪。 Fig 6, 服务依赖 Fig 7, 高峰期单个服务延迟致雪崩效应 经过多年的探索和实践，业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践，主要包括： Fig 8, 弹性电路保护状态图 电路熔断器模式 (Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器，如果家里的电路发生短路，熔断器能够主动熔断电路，以避免灾难性损失。在分布式系统中应用电路熔断器模式后，当目标服务慢或者大量超时，调用方能够主动熔断，以防止服务被进一步拖垮；如果情况又好转了，电路又能自动恢复，这就是所谓的弹性容错，系统有自恢复能力。下图 Fig 8 是一个典型的具备弹性恢复能力的电路保护器状态图，正常状态下，电路处于关闭状态 (Closed)，如果调用持续出错或者超时，电路被打开进入熔断状态 (Open)，后续一段时间内的所有调用都会被拒绝 (Fail Fast)，一段时间以后，保护器会尝试进入半熔断状态 (Half-Open)，允许少量请求进来尝试，如果调用仍然失败，则回到熔断状态，如果调用成功，则回到电路闭合状态。舱壁隔离模式 (Bulkhead Isolation Pattern)，顾名思义，该模式像舱壁一样对资源或失败单元进行隔离，如果一个船舱破了进水，只损失一个船舱，其它船舱可以不受影响 。线程隔离 (Thread Isolation) 就是舱壁隔离模式的一个例子，假定一个应用程序 A 调用了 Svc1/Svc2/Svc3 三个服务，且部署 A 的容器一共有 120 个工作线程，采用线程隔离机制，可以给对 Svc1/Svc2/Svc3 的调用各分配 40 个线程，当 Svc2 慢了，给 Svc2 分配的 40 个线程因慢而阻塞并最终耗尽，线程隔离可以保证给 Svc1/Svc3 分配的 80 个线程可以不受影响，如果没有这种隔离机制，当 Svc2 慢的时候，120 个工作线程会很快全部被对 Svc2 的调用吃光，整个应用程序会全部慢下来。限流 (Rate Limiting/Load Shedder)，服务总有容量限制，没有限流机制的服务很容易在突发流量 (秒杀，双十一) 时被冲垮。限流通常指对服务限定并发访问量，比如单位时间只允许 100 个并发调用，对超过这个限制的请求要拒绝并回退。回退 (fallback)，在熔断或者限流发生的时候，应用程序的后续处理逻辑是什么？回退是系统的弹性恢复能力，常见的处理策略有，直接抛出异常，也称快速失败 (Fail Fast)，也可以返回空值或缺省值，还可以返回备份数据，如果主服务熔断了，可以从备份服务获取数据。Netflix 将上述容错模式和最佳实践集成到一个称为 Hystrix 的开源组件中，凡是需要容错的依赖点 (服务，缓存，数据库访问等)，开发人员只需要将调用封装在 Hystrix Command 里头，则相关调用就自动置于 Hystrix 的弹性容错保护之下。Hystrix 组件已经在 Netflix 经过多年运维验证，是 Netflix 微服务平台稳定性和弹性的基石，正逐渐被社区接受为标准容错组件。 服务框架微服务化以后，为了让业务开发人员专注于业务逻辑实现，避免冗余和重复劳动，规范研发提升效率，必然要将一些公共关注点推到框架层面。服务框架 (Fig 9) 主要封装公共关注点逻辑，包括： Fig 9, 服务框架 服务注册、发现、负载均衡和健康检查，假定采用进程内 LB 方案，那么服务自注册一般统一做在服务器端框架中，健康检查逻辑由具体业务服务定制，框架层提供调用健康检查逻辑的机制，服务发现和负载均衡则集成在服务客户端框架中。监控日志，框架一方面要记录重要的框架层日志、metrics 和调用链数据，还要将日志、metrics 等接口暴露出来，让业务层能根据需要记录业务日志数据。在运行环境中，所有日志数据一般集中落地到企业后台日志系统，做进一步分析和处理。REST/RPC 和序列化，框架层要支持将业务逻辑以 HTTP/REST 或者 RPC 方式暴露出来，HTTP/REST 是当前主流 API 暴露方式，在性能要求高的场合则可采用 Binary/RPC 方式。针对当前多样化的设备类型 (浏览器、普通 PC、无线设备等)，框架层要支持可定制的序列化机制，例如，对浏览器，框架支持输出 Ajax 友好的 JSON 消息格式，而对无线设备上的 Native App，框架支持输出性能高的 Binary 消息格式。配置，除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和配置。限流和容错，框架集成限流容错组件，能够在运行时自动限流和容错，保护服务，如果进一步和动态配置相结合，还可以实现动态限流和熔断。管理接口，框架集成管理接口，一方面可以在线查看框架和服务内部状态，同时还可以动态调整内部状态，对调试、监控和管理能提供快速反馈。Spring Boot 微框架的 Actuator 模块就是一个强大的管理接口。统一错误处理，对于框架层和服务的内部异常，如果框架层能够统一处理并记录日志，对服务监控和快速问题定位有很大帮助。安全，安全和访问控制逻辑可以在框架层统一进行封装，可做成插件形式，具体业务服务根据需要加载相关安全插件。文档自动生成，文档的书写和同步一直是一个痛点，框架层如果能支持文档的自动生成和同步，会给使用 API 的开发和测试人员带来极大便利。Swagger 是一种流行 Restful API 的文档方案。当前业界比较成熟的微服务框架有 Netflix 的 Karyon/Ribbon，Spring 的 Spring Boot/Cloud，阿里的 Dubbo 等。 运行期配置管理服务一般有很多依赖配置，例如访问数据库有连接字符串配置，连接池大小和连接超时配置，这些配置在不同环境 (开发 / 测试 / 生产) 一般不同，比如生产环境需要配连接池，而开发测试环境可能不配，另外有些参数配置在运行期可能还要动态调整，例如，运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置，简化架构如下图 (Fig 10): Fig 10, 服务配置中心 动态配置存放在集中的配置服务器上，用户通过管理界面配置和调整服务配置，具体服务通过定期拉 (Scheduled Pull) 的方式或者服务器推 (Server-side Push) 的方式更新动态配置，拉方式比较可靠，但会有延迟同时有无效网络开销 (假设配置不常更新)，服务器推方式能及时更新配置，但是实现较复杂，一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题，对于大规模服务化环境，配置中心还要考虑分布式和高可用问题。 配置中心比较成熟的开源方案有百度的 Disconf，360 的 QConf，Spring 的 Cloud Config 和阿里的 Diamond 等。 Netflix 的微服务框架Netflix 是一家成功实践微服务架构的互联网公司，几年前，Netflix 就把它的几乎整个微服务框架栈开源贡献给了社区，这些框架和组件包括： Eureka:　服务注册发现框架Zuul:　服务网关Karyon:　服务端框架Ribbon:　客户端框架Hystrix: 服务容错组件Archaius: 服务配置组件Servo: Metrics 组件Blitz4j: 日志组件下图 Fig 11 展示了基于这些组件构建的一个微服务框架体系，来自 recipes-rss。 Fig 11, 基于 Netflix 开源组件的微服务框架 Netflix 的开源框架组件已经在 Netflix 的大规模分布式微服务环境中经过多年的生产实战验证，正逐步被社区接受为构造微服务框架的标准组件。Pivotal 去年推出的 Spring Cloud 开源产品，主要是基于对 Netflix 开源组件的进一步封装，方便 Spring 开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说，充分利用或参考借鉴 Netflix 的开源微服务组件 (或 Spring Cloud)，在此基础上进行必要的企业定制，无疑是通向微服务架构的捷径。 原文地址：https://www.infoq.cn/article/basis-frameworkto-implement-micro-service#anch130564%20%EF%BC%8C

如果能时光倒流，回到过去，作为一个开发人员，你可以告诉自己在职业生涯初期应该读一本， 你会选择哪本书呢。我希望这个书单列表内容丰富，可以涵盖很多东西。” 1、《代码大全》 史蒂夫·迈克康奈尔 推荐数：1684 “优秀的编程实践的百科全书，《代码大全》注重个人技术，其中所有东西加起来， 就是我们本能所说的“编写整洁的代码”。这本书有50页在谈论代码布局。” —— Joel Spolsky 对于新手来说，这本书中的观念有点高阶了。到你准备阅读此书时，你应该已经知道并实践过书中99%的观念。– esac Steve McConnell的原作《代码大全》(第1版)是公认的关于编程的最佳实践指南之一， 在过去的十多年间，本书一直在帮助开发人员编写更好的软件。 现在，作者将这本经典著作全新演绎，融入了最前沿的实践技术，加入了上百个崭新的代码示例， 充分展示了软件构建的艺术性和科学性。 McConnell汇集了来自研究机构、学术界以及业界日常实践的主要知识， 把最高效的技术和最重要的原理交织融会为这本既清晰又实用的指南。 无论您的经验水平如何，也不管您在怎样的开发环境中工作，也无论项目是大是小， 本书都将激发您的思维并帮助您构建高品质的代码。 《代码大全（第2版）)》做了全面的更新，增加了很多与时俱进的内容，包括对新语言、新的开发过程与方法论的讨论等等。 2、《程序员修炼之道》 推荐数：1504 对于那些已经学习过编程机制的程序员来说，这是一本卓越的书。 或许他们还是在校生，但对要自己做什么，还感觉不是很安全。 就像草图和架构之间的差别。虽然你在学校课堂上学到的是画图，你也可以画的很漂亮， 但如果你觉得你不太知道从哪儿下手，如果某人要你独自画一个P2P的音乐交换网络图，那这本书就适合你了。—— Joel 《程序员修炼之道:从小工到专家》内容简介：《程序员修炼之道》由一系列独立的部分组成， 涵盖的主题从个人责任、职业发展，知道用于使代码保持灵活、并且易于改编和复用的各种架构技术， 利用许多富有娱乐性的奇闻轶事、有思想性的例子及有趣的类比， 全面阐释了软件开发的许多不同方面的最佳实践和重大陷阱。 无论你是初学者，是有经验的程序员，还是软件项目经理，《程序员修炼之道:从小工到专家》都适合你阅读。 3、《计算机程序的构造和解释》 推荐数：916 就个人而言，这本书目前为止对我影响醉倒的一本编程书。 《代码大全》、《重构》和《设计模式》这些经典书会教给你高效的工作习惯和交易细节。 其他像《人件集》、《计算机编程心理学》和《人月神话》这些书会深入软件开发的心理层面。 其他书籍则处理算法。这些书都有自己所属的位置。 然而《计算机程序的构造和解释》与这些不同。 这是一本会启发你的书，它会燃起你编写出色程序的热情； 它还将教会你认识并欣赏美； 它会让你有种敬畏，让你难以抑制地渴望学习更多的东西。 其他书或许会让你成为一位更出色的程序员，但此书将一定会让你成为一名程序员。 同时，你将会学到其他东西，函数式编程（第三章）、惰性计算、元编程、虚拟机、解释器和编译器。 一些人认为此书不适合新手。 个人认为，虽然我并不完全认同要有一些编程经验才能读此书，但我还是一定推荐给初学者。 毕竟这本书是写给著名的6.001，是麻省理工学院的入门编程课程。 此书或许需要多做努力（尤其你在做练习的时候，你也应当如此），但这个价是对得起这本书的。 4、《C程序设计语言》 推荐数：774 这本书简洁易读，会教给你三件事：C 编程语言；如何像程序员一样思考；底层计算模型。 （这对理解“底层”非常重要）—— Nathan 《C程序设计语言》(第2版新版)讲述深入浅出，配合典型例证，通俗易懂，实用性强， 适合作为大专院校计算机专业或非计算机专业的C语言教材，也可以作为从事计算机相关软硬件开发的技术人员的参考书。 《C程序设计语言》(第2版新版)原著即为C语言的设计者之一Dennis M.Ritchie和著名的计算机科学家Brian W.Kernighan合著的 一本介绍C语言的权威经典著作。 我们现在见到的大量论述C语言程序设计的教材和专著均以此书为蓝本。 原著第1版中介绍的C语言成为后来广泛使用的C语言版本——标准C的基础。 人们熟知的“hello,world”程序就是由本书首次引入的，现在，这一程序已经成为所有程序设计语言入门的第一课。 5、《算法导论》 推荐数：671 《代码大全》教你如何正确编程； 《人月神话》教你如何正确管理； 《设计模式》教你如何正确设计…… 在我看来，代码只是一个工具，并非精髓。 开发软件的主要部分是创建新算法或重新实现现有算法。 其他部分则像重新组装乐高砖块或创建“管理”层。 我依然梦想这样的工作，我的大部分时间（>50%）是在写算法，其他“管理”细节则留给其他人…… —— Ran Biron 经典的算法书,被亚马逊网，《程序员》等评选为2006年最受读者喜爱的十大IT图书之一。 算法领域的标准教材，全球多所知名大学选用 MIT名师联手铸就，被誉为“计算机算法的圣经” 编写上采用了“五个一”，即一章介绍一个算法、一种设计技术、一个应用领域和一个相关话题。 6、《重构：改善既有代码的设计》 推荐数：617 《重构:改善既有代码的设计》清晰地揭示了重构的过程，解释了重构的原理和最佳实践方式， 并给出了何时以及何地应该开始挖掘代码以求改善。 书中给出了70多个可行的重构，每个重构都介绍了一种经过验证的代码变换手法的动机和技术。 《重构:改善既有代码的设计》提出的重构准则将帮助你一次一小步地修改你的代码，从而减少了开发过程中的风险。 《重构:改善既有代码的设计》适合软件开发人员、项目管理人员等阅读， 也可作为高等院校计算机及相关专业师生的参考读物。 我想我不得不推荐《重构》：改进现有代码的设计。—— Martin 我必须承认，我最喜欢的编程语录是出自这本书：任何一个傻瓜都能写出计算机能理解的程序， 而优秀的程序员却能写出别人能读得懂的程序。—— Martin Fowler 7、《设计模式》 推荐数：617 自1995年出版以来，本书一直名列Amazon和各大书店销售榜前列。 近10年后，本书仍是Addison-Wesley公司2003年最畅销的图书之一。 中文版销售逾4万册。 就我而言，我认为四人帮编著的《设计模式》是一本极为有用的书。 虽然此书并不像其他建议一样有关“元”编程，但它强调封装诸如模式一类的优秀编程技术， 因而鼓励其他人提出新模式和反模式（antipatterns），并运用于编程对话中。—— Chris Jester-Young 8、《人月神话》 推荐数：588 在软件领域，很少能有像《人月神话》一样具有深远影响力并且畅销不衰的著作。 Brooks博士为人们管理复杂项目提供了最具洞察力的见解。 既有很多发人深省的观点，又有大量软件工程的实践。 本书内容来自Brooks博士在IBM公司System/360家族和OS/360中的项目管理经验。 该书英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄中等多种语言，全球销量数百万册。 确立了其在行业内的经典地位。 9、《计算机程序设计艺术》 推荐数：542 《计算机程序设计艺术》系列著作对计算机领域产生了深远的影响。 这一系列堪称一项浩大的工程，自1962年开始编写，计划出版7卷，目前已经出版了4卷。 《美国科学家》杂志曾将这套书与爱因斯坦的《相对论》等书并列称为20世纪最重要的12本物理学著作。 目前Knuth正将毕生精力投入到这部史诗性著作的撰写中。 这是高德纳倾注心血写的一本书。—— Peter Coulton 10、《编译原理》（龙书） 推荐数：462 我很奇怪，居然没人提到龙书。（或许已有推荐，我没有看到）。 我从没忘过此书的第一版封面。 此书让我知道了编译器是多么地神奇绝妙。- DB 11、《深入浅出设计模式》 推荐数：445 强大的写作阵容。 《Head First设计模式》(中文版) 作者Eric Freeman； ElElisabeth Freeman是作家、讲师和技术顾问。 Eric拥有耶鲁大学的计算机科学博士学位，E1isabath拥有耶鲁大学的计算机科学硕士学位。 Kathy Sierra(javaranch．com的创始人)FHBert Bates是畅销的HeadFirst系列书籍的创立者，也是Sun公司Java开发员认证考试的开发者。 本书的产品设计应用神经生物学、认知科学，以及学习理论，这使得这本书能够将这些知识深深地印在你的脑海里， 不容易被遗忘。 本书的编写方式采用引导式教学，不直接告诉你该怎么做，而是利用故事当作引子，带领读者思考并想办法解决问题。 解决问题的过程中又会产生一些新的问题，再继续思考、继续解决问题，这样可以加深体会。 作者以大量的生活化故事当背景，例如第1章是鸭子，第2章是气象站，第3章是咖啡店， 书中搭配大量的插图(几乎每一页都有图)，所以阅读起来生动有趣，不会感觉到昏昏欲睡。 作者还利用歪歪斜斜的手写字体，增加“现场感”。 精心设计许多爆笑的对白，让学习过程不会太枯燥。 还有模式告白节目，将设计模式拟人化成节目来宾，畅谈其内在的一切。 每一章都有数目不等的测验题。 每章最后有一页要点整理，这也是精华所在，我都是利用这一页做复习。 我知道四人帮的《设计模式》是一本标准书，但倒不如先看看这部大部头，此书更为简易。 一旦你了解了解了基本原则，可以去看四人帮的那本圣经了。- Calanus 12、《哥德尔、艾舍尔、巴赫书：集异璧之大成》 推荐数：437 如果下昂真正深入阅读，我推荐道格拉斯·侯世达（Douglas Hofstadter）的《哥德尔、艾舍尔、巴赫书》。 他极为深入研究了程序员每日都要面对的问题：递归、验证、证明和布尔代数。 这是一本很出色的读物，难度不大，偶尔有挑战，一旦你要鏖战到底，将是非常值得的。 – Jonik 13、《代码整洁之道》 推荐数：329 细节之中自有天地，整洁成就卓越代码 尽管糟糕的代码也能运行，但如果代码不整洁，会使整个开发团队泥足深陷， 写得不好的代码每年都要耗费难以计数的时间和资源。 然而这种情况并非无法避免。 著名软件专家RoberfC.Marlin在《代码整洁之道》中为你呈现出了革命性的视野。 Martin携同ObjectMetltor公司的同事，从他们有关整洁代码的最佳敏捷实践中提炼出软件技艺的价值观， 以飨读者，让你成为更优秀的程序员——只要你着手研读《代码整洁之道》。 阅读《代码整洁之道》需要你做些什么呢。你将阅读代码——大量代码。 《代码整洁之道》促使你思考代码中何谓正确，何谓错误。 更重要的是，《代码整洁之道》将促使你重新评估自己的专业价值观，以及对自己技艺的承诺。 从《代码整洁之道》中可以学到： 好代码和糟糕的代码之间的区别； 如何编写好代码，如何将糟糕的代码转化为好代码； 如何创建好名称、好函数、好对象和好类； 如何格式化代码以实现其可读性的最大化； 如何在不妨碍代码逻辑的前提下充分实现错误处理； 如何进行单元测试和测试驱动开发。 虽然《代码整洁之道》和《代码大全》有很多共同之处，但它有更为简洁更为实际的清晰例子。 – Craig P. Motlin 14、《Effective C++》和《More Effective C++》 推荐数：297 在我职业生涯早期，Scott Meyer的《Effective C++》和后续的《More Effective C++》都对我的编程能力有着直接影响。 正如当时的一位朋友所说，这些书缩短你培养编程技能的过程，而其他人可能要花费数年。 去年对我影响最大的一本书是《大教堂与市集》，该书教会我很有关开源开发过程如何运作，和如何处理我代码中的Bug。 – John Channing 15、《编程珠玑》 推荐数：282 多年以来，当程序员们推选出最心爱的计算机图书时，《编程珠玑》总是位列前列。 正如自然界里珍珠出自细沙对牡蛎的磨砺，计算机科学大师Jon Bentley以其独有的洞察力和创造力， 从磨砺程序员的实际问题中凝结出一篇篇不朽的编程“珠玑”， 成为世界计算机界名刊《ACM通讯》历史上最受欢迎的专栏， 最终结集为两部不朽的计算机科学经典名著，影响和激励着一代又一代程序员和计算机科学工作者。 本书为第一卷，主要讨论计算机科学中最本质的问题：如何正确选择和高效地实现算法。 尽管我不得不羞愧地承认，书中一半的东西我都没有理解，但我真的推荐《编程珠玑》，书中有些令人惊奇的东西。 – Matt Warren 16、《修改代码的艺术》by Michael Feathers 本书是继《重构》和《重构与模式》之后探讨修改代码技术的又一里程碑式的著作， 而且从涵盖面和深度上都超过了前两部经典。 书中不仅讲述面向对象语言（Java、C#和C++）代码，也有专章讨论C这样的过程式语言。 作者将理解、测试和修改代码的原理、技术和最新工具（自动化重构工具、单元测试框架、仿对象、集成测试框架等）， 与解依赖技术和大量开发和设计优秀代码的原则、最佳实践相结合，许多内容非常深入，而且常常发前人所未发。 书中处处体现出作者独到的洞察力，以及多年开发和指导软件项目所积累的丰富经验和深厚功力。 通过这部集大成之作，你不仅能掌握最顶尖的修改代码技术，还可以大大提高对代码和软件开发的领悟力。 我认为没有任何一本书能向这本书一样影响了我的编程观点。 它明确地告诉你如何处理其他人的代码，含蓄地教会你避免哪些（以及为什么要避免）。- Wolfbyte 同意。很多开发人员讨论用干净的石板来编写软件。 但我想几乎所有开发人员的某些时候是在吃其他开发人员的狗食。– Bernard Dy 17、《编码：隐匿在计算机软硬件背后的语言》 这是一本讲述计算机工作原理的书。 不过，你千万不要因为“工作原理”之类的字眼就武断地认为，它是晦涩而难懂的。 作者用丰富的想象和清晰的笔墨将看似繁杂的理论阐述得通俗易懂，你丝毫不会感到枯燥和生硬。 更重要的是，你会因此而获得对计算机工作原理较深刻的理解。 这种理解不是抽象层面上的，而是具有一定深度的，这种深度甚至不逊于“电气工程师”和“程序员”的理解。 不管你是计算机高手，还是对这个神奇的机器充满敬畏之心的菜鸟， 都不妨翻阅一下《编码:隐匿在计算机软硬件背后的语言》，读一读大师的经典作品，必然会有收获。 我推荐Charles Petzold的《编码》。 在这个充满工具和IDE的年代，很多复杂度已经从程序员那“抽取”走了，这本书一本开眼之作。 – hemil 18、《禅与摩托车维修艺术 / Zen and the Art of Motorcycle Maintenance》 对我影响最大的那本书是 Robert Pirsig 的《禅与摩托车维修艺术》。 不管你做什么事，总是要力求完美，彻底了解你手中的工具和任务，更为重要的是， 要有乐趣（因为如果你做事有乐趣，一切将自发引向更好的结果）。 – akr 19、《Peopleware / 人件集:人性化的软件开发》 Demarco 和 Lister 表明，软件开发中的首要问题是人，并非技术。 他们的答案并不简单，只是令人难以置信的成功。 第二版新增加了八章内容。 – Eduardo Molteni 20、《Coders at Work / 编程人生》 这是一本访谈笔录，记录了当今最具个人魅力的15位软件先驱的编程生涯。 包括DonaldKnuth、Jamie Zawinski、Joshua Bloch、Ken Thompson等在内的业界传奇人物，为我们讲述了 他们是怎么学习编程的，在编程过程中发现了什么以及他们对未来的看法， 并对诸如应该如何设计软件等长久以来一直困扰很多程序员的问题谈了自己的观点。 一本非常有影响力的书，可以从中学到一些业界顶级人士的经验，了解他们如何思考并工作。 – Jahanzeb Farooq 21、《Surely You’re Joking, Mr. Feynman! / 别闹了，费曼先生。》 虽然这本书可能有点偏题，但不管你信不信，这本书曾在计算机科学专业课程的阅读列表之上。 一个优秀的角色模型，一本有关好奇心的优秀书籍。 – mike511 22、《Effective Java 中文版》 此书第二版教你如何编写漂亮并高效的代码，虽然这是一本Java书，但其中有很多跨语言的理念。 – Marcio Aguiar 23、《Patterns of Enterprise Application Architecture / 企业应用架构模式》 很奇怪，还没人推荐 Martin Fowler 的《企业应用架构模式》- levi rosol 24、《The Little Schemer》和《The Seasoned Schemer》 nmiranda 这两本是LISP的英文书，尚无中文版。 美国东北大学网站上也有电子版。 25、《交互设计之路》英文名：《The Inmates Are Running The Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity》该书作者：Alan Cooper，人称Visual Basic之父，交互设计之父。 本书是基于众多商务案例，讲述如何创建更好的、高客户忠诚度的软件产品和基于软件的高科技产品的书。 本书列举了很多真实可信的实际例子，说明目前在软件产品和基于软件的高科技产品中，普遍存在着“难用”的问题。 作者认为，“难用”问题是由这些产品中存在着的高度“认知摩擦”引起的， 而产生这个问题的根源在于现今软件开发过程中欠缺了一个为用户利益着想的前期“交互设计”阶段。 “难用”的产品不仅损害了用户的利益，最终也将导致企业的失败。 本书通过一些生动的实例，让人信服地讲述了由作者倡导的“目标导向”交互设计方法在解决“难用”问题方面的有效性， 证实了只有改变现有观念，才能有效地在开发过程中引入交互设计，将产品的设计引向成功。 本书虽然是一本面向商务人员而编写的书，但也适合于所有参与软件产品和基于软件的高科技产品开发的专业人士， 以及关心软件行业和高科技行业现状与发展的人士阅读。 他还有另一本中文版著作：《About Face 3 交互设计精髓》 26、《Why’s (Poignant) Guide to Ruby 》 如果你不是程序员，阅读此书可能会很有趣，但如果你已经是个程序员，可能会有点乏味。 27、《Unix编程艺术》 It is useful regardless operating system you use. – J.F. Sebastian 不管你使用什么操作系统，这本书都很有用。 – J.F. Sebastian 28、《高效程序员的45个习惯：敏捷开发修炼之道》 45个习惯，分为7个方面：工作态度、学习、软件交付、反馈、编码、调试和协作。 每一个具体的习惯里，一开始提出一个谬论，然后展开分析，之后有正队性地提出正确的做法，并设身处地地讲出了正确做法给你个人的“切身感受”，最后列出几条注意事项，帮助你修正自己的做法（“平衡的艺术”）。 29、《测试驱动开发》 前面已经提到的很多书都启发了我，并影响了我，但这本书每位程序员都应该读。 它向我展示了单元测试和TDD的重要性，并让我很快上手。 – Curro 我不关心你的代码有多好或优雅。 如果你没有测试，你或许就如同没有编写代码。 这本书得到的推荐数应该更高些。 人们讨论编写用户喜欢的软件，或既设计出色并健壮的高效代码，但如果你的软件有一堆bug，谈论那些东西毫无意义。– Adam Gent 30、《点石成金:访客至上的网页设计秘笈》 可用性设计是Web设计中最重要也是难度最大的一项任务。 《点石成金－访客至上的网页设计秘笈（原书第二版）》作者根据多年从业的经验，剖析用户的心理， 在用户使用的模式、为扫描进行设计、导航设计、主页布局、可用性测试等方面提出了许多独特的观点， 并给出了大量简单、易行的可用性设计的建议。 本书短小精炼，语言轻松诙谐，书中穿插大量色彩丰富的屏幕截图、趣味丛生的卡通插图以及包含大量信息的图表， 使枯燥的设计原理变得平易近人。 本书适合从事Web设计和Web开发的技术人员阅读，特别适合为如何留住访问者而苦恼的网站/网页设计人员阅读。 这是一本关于Web设计原则而不是Web设计技术的书。 本书作者是Web设计专家，具有丰富的实践经验。 他用幽默的语言为你揭示Web设计中重要但却容易被忽视的问题，只需几个小时， 你便能对照书中讲授的设计原则找到网站设计的症结所在，令你的网站焕然一新。

12月17日更新 请问下同时消费多个topic的情况下，在richmap里面可以获取到当前消息所属的topic吗？ 各位大佬，你们实时都是怎样重跑数据的? 有木有大神知道Flink能否消费多个kafka集群的数据？ 这个问题有人遇到吗? 你们实时读取广业务库到kafka是通过什么读的？kafka connector 的原理是定时去轮询，这样如果表多了，会不会影响业务库的性能？甚至把业务库搞挂？ 有没有flink 1.9 连接 hive的例子啊?官网文档试了，没成功 请问各位是怎么解决实时流数据倾斜的？ 请问一下，对于有状态的任务，如果任务做代码升级的时候，可否修改BoundedOutOfOrdernessTimestampExtractor的maxOutOfOrderness呢？是否会有影响数据逻辑的地方呢？ 老哥们有做过统计从0点开始截止到现在时刻的累计用户数吗？ 比如五分钟输出一次，就是7点输出0点到7点的累计用户，7:05输出0点到7:05的累计用户。 但是我这里有多个维度，现在用redis来做的。 想知道有没有更好的姿势？ 实时数仓用什么存储介质来存储维表，维表有大有小，大的大概5千万左右。 各位大神有什么建议和经验分享吗？ 请教个问题，就是flink的窗口触发必须是有数据才会触发吗？我现在有个这样的需求，就是存在窗口内没有流数据进入，但是窗口结束是要触发去外部系统获取上一个窗口的结果值作为本次窗口的结果值！现在没有流数据进入窗口结束时如何触发？ kafkaSource.setStartFromTimestamp(timestamp); 发现kafkasource从指定时间开始消费，有些topic有效，有效topic无效，大佬们有遇到过吗? 各位大佬，flink两个table join的时候，为什么打印不出来数据，已经赋了关联条件了，但是也不报错 各位大佬 请教一下 一个faile的任务 会在这里面存储展示多久啊？ 各位大佬，我的程序每五分钟一个窗口做了基础指标的统计，同时还想统计全天的Uv，这个是用State就能实现吗？ 大佬们，flink的redis sink是不是只适用redis2.8.5版本？ 有CEP 源码中文注释的发出来学习一下吗？ 有没有拿flink和tensorflow集成的？ 那位大神，给一个java版的flink1.7 读取kafka数据，做实时监控和统计的功能的代码案例。 请问下风控大佬，flink为风控引擎做数据支撑的时候，怎么应对风控规则的不断变化，比如说登录场景需要实时计算近十分钟内登录次数超过20次用户，这个规则可能会变成计算近五分钟内登录次数超过20次的。 想了解一下大家线上Flink作业一般开始的时候都分配多少内存？广播没办法改CEP flink支持多流（大于2流）join吗？ 谁能帮忙提供一下flink的多并行度的情况下，怎么保证数据有序 例如map并行度为2 那就可能出现数据乱序的情况啊 请教下现在从哪里可以可以看单任务的运行状况和内存占用情况,flink页面上能看单个任务的内存、cpu 大佬们 flink1.9 停止任务手动保存savepoint的命令是啥？ flink 一个流计算多个任务和 还是一个流一个任务好？ flink 1.9 on yarn， 自定义个connector里面用了jni， failover以后 就起不来了， 报错重复load so的问题。 我想问一下 这个，怎么解决。 难道flink 里面不能用jni吗。 ide里面调试没有问题，部署到集群就会报错了，可能什么问题？ 请教一下对于长时间耗内存很大的任务，大家都是开checkpoint机制，采用rocksdb做状态后端吗？ 请问下大佬，flink jdbc读取mysql，tinyin字段类型自动转化为Boolean有没有好的解决方法 Flink 1.9版本的Blink查询优化器，Hive集成，Python API这几个功能好像都是预览版，请问群里有大佬生产环境中使用这些功能了吗？ 想做一个监控或数据分析的功能，如果我flink 的datastreaming实现消费Kafka的数据，但是我监控的规则数据会增加或修改，但是不想停这个正在运行的flink程序，要如何传递这个动态变化的规则数据，大神给个思路，是用ConnectedStream这个吗？还是用Broadcast ？还有一个，比如我的规则数据是存放在Mysql表中，用什么事件隔30秒去触发读取mysql规则表呢？谢谢！ 想做一个监控或数据分析的功能，如果我flink 的datastreaming实现消费Kafka的数据，但是我监控的规则数据会增加或修改，但是不想停这个正在运行的flink程序，要如何传递这个动态变化的规则数据，大神给个思路，是用ConnectedStream这个吗？还是用Broadcast ？还有一个，比如我的规则数据是存放在Mysql表中，用什么事件隔30秒去触发读取mysql规则表呢？谢谢！ 各位大佬，在一个 Job 计算过程中，查询 MySQL 来补全额外数据，是一个好的实践嘛？还是说流处理过程中应该尽量避免查询额外的数据？ Flink web UI是jquery写的吗？ 12月9日更新 成功做完一次checkpoint后，会覆盖上一次的checkpoint吗？ 数据量较大时，flink实时写入hbase能够异步写入吗？ flink的异步io，是不是只是适合异步读取，并不适合异步写入呀？ 请问一下，flink将结果sink到redis里面会不会对存储的IO造成很大的压力，如何批量的输出结果呢？ 大佬们，flink 1.9.0版本里DataStream api,若从kafka里加载完数据以后，从这一个流中获取数据进行两条业务线的操作，是可以的吗？ flink 中的rocksdb状态怎么样能可视化的查看有大佬知道吗？ 感觉flink 并不怎么适合做hive 中的计算引擎来提升hive 表的查询速度 大佬们，task端rocksdb状态 保存路径默认是在哪里的啊？我想挂载个新磁盘 把状态存到那里去 flink 的state 在窗口滑动到下一个窗口时候 上一个窗口销毁时候 state会自己清除吗？ 求助各位大佬，一个sql里面包含有几个大的hop滑动窗口，如15个小时和24个小时，滑动步长为5分钟，这样就会产生很多overlap 数据，导致状态会很快就达到几百g，然后作业内存也很快达到瓶颈就oom了，然后作业就不断重启，很不稳定，请问这个业务场景有什么有效的解决方案么？ 使用jdbcsink的时候，如果连接长时间不使用 就会被关掉，有人遇到过吗？使用的是ddl的方式 如何向云邪大佬咨询FLink相关技术问题？ 请问各位公司有专门开发自己的实时计算平台的吗？ 请问各位公司有专门开发自己的实时计算平台的吗？ 有哪位大佬有cdh集成安装flink的文档或者手册？ 有哪位大佬有cdh集成安装flink的文档或者手册？ 想问下老哥们都是怎么统计一段时间的UV的？ 是直接用window然后count嘛？ Flink是不是也是这样的？ 请问现在如有个实时程序，根据一个mysql的维表来清洗，但是我这个mysql表里面就只有几条信息且可能会变。 我想同一个定时器去读mysql，然后存在对象中，流清洗的时候读取这个数据，这个想法可行吗？我目前在主类里面定义一个对象，然后往里面更新，发现下面的map方法之类的读不到我更新进去的值 有大佬做过flink—sql的血缘分析吗？ 12月3日更新 请教一下，为什么我flume已经登录成功了keytab认证的kafka集群，但是就是消费不到数据呢？ flink 写入mysql 很长一段时间没有写入，报错怎么解决呢? flink timestamp转换为date类型，有什么函数吗 Run a single Flink job on YARN 我采用这种模式提交任务，出现无法找到 开启 HA 的ResourceManager Failed to connect to server: xxxxx:8032: retries get failed due to exceeded maximum allowed retries number: 0 有大佬遇到过吗 ？ 各位大佬，请问有Flink写S3的方案吗？ flink 连接hbase 只支持1.4.3版本？ onnector: type: hbase version: "1.4.3" 请问 flink1.9能跑在hadoop3集群上吗? 滑动窗口 排序 报错这个是什么原因呢? 这个pravega和kafka有啥区别? flink 开发里数据源配置了RDS，但是在RDS里没有看到创建的表，是为什么呢？ Tumbling Window里的数据，是等窗口期内的数据到齐之后一次性处理，还是到了一条就处理一条啊 双流join后再做time window grouping. 但是双流join会丢失时间属性，请问大家如何解决 stream processing with apache flink，这本书的中译版 现在可以买吗? flink on yarn时，jm和tm占用的内存最小是600M，这个可以修改吗？ 各位大佬，使用默认的窗口Trigger，在什么情况下会触发两次啊？窗口关闭后，然后还来了这个窗口期内的数据，并且开了allowedLateness么？ flink web里可以像storm那样 看每条数据在该算子中的平均耗时吗？ 各位大佬，flink任务的并发数调大到160+以后，每隔几十分钟就会出现一次TM节点连接丢失的异常，导致任务重启。并发在100时运行比较稳定，哪位大佬可以提供下排查的思路？ 感觉stateful function 是下一个要发力的点，这个现在有应用案例吗？ 我有2个子网（a子网，b子网）用vpn联通，vpn几周可能会断一次。a子网有一个kafka集群，b子网运行我自己的flink集群和应用，b子网的flink应用连接到a子网的kafka集群接收消息来处理入库到数仓去。我的问题是，如果vpn断开，flink consumer会异常整个作业退出吗？如果作业退出，我重连vpn后，能从auto checkpoint再把flink应用恢复到出错时flink kafka consumer应该读取的partition/offset位置吗？flink的checkpoint除了保存自己开发的算子里的state，kafkaconsumer里的partition/offset也会保存和恢复吗？ flink的反压为什么不加入metrics呢 hdfs是不是和flink共用一个集群? flink消费kafka，可以从指定时间消费的吗？目前提供的接口只是根据offset消费？有人知道怎么处理？ flink 的Keyby是不是只是repartition而已？没有将key相同的数据放到一个组合里面 电商大屏 大家推荐用什么来做吗？ 我比较倾向用数据库，因为有些数据需要join其他表，flink充当了什么角色，对这个有点迷，比如统计当天订单量，卖了多少钱，各个省的销量，销售金额，各个品类的销售量销售金额 开源1.9的sql中怎么把watermark给用起来，有大神知道吗？ 有没有人能有一些flink的教程 代码之类的分享啊 采用了checkpoint,程序停止了之后，什么都不改，直接重启，还是能接着继续运行吗？如果可以的话，savepoint的意义又是什么呢? 有人做过flink 的tpc-ds测试吗，能不能分享一下操作的流程方法 checkpoint是有时间间隔的，也就可以理解为checkpoint是以批量操作的，那如果还没进行ckecnpoint就挂了，下次从最新的一次checkpoint重启，不是重复消费了？ kafka是可以批量读取数据，但是flink是一条一条处理的，应该也可以一条一条提交吧。 各位大佬，flink sql目前是不是不支持tumbling window join，有人了解吗？ 你们的HDFS是装在taskmanager上还是完全分开的,请问大佬们有遇到这种情况吗？ 大佬们flink检查点存hdfs的话怎么自动清理文件啊 一个128M很快磁盘就满了 有谁遇到过这个问题? 请教一下各位，这段代码里面，我想加一个trigger，实现每次有数据进window时候，就输出，而不是等到window结束再输出，应该怎么加？ 麻烦问下 flink on yarn 执行 客户端启动时 报上面错,是什么原因造成的 求大佬指点 ERROR org.apache.flink.client.program.rest.RestClusterClient - Error while shutting down cluster java.util.concurrent.ExecutionException: org.apache.flink.runtime.concurrent.FutureUtils$RetryException: Could not complete the operation. Number of retries has been exhausted. 大家怎么能动态的改变 flink WindowFunction 窗口数据时间 flink on yarn之后。yarn的日志目录被写满，大家如配置的？ Flink1.9 启动 yarn-session报这个错误 怎么破？ yarn 模式下，checkpoint 是存在 JobManager的，提交任务也是提交给 JobManager 的吧？ heckpoint机制，会不会把window里面的数据全部放checkpoint里面？ Flink On Yarn的模式下，如果通过REST API 停止Job,并触发savepiont呢 jenkins自动化部署flink的job，一般用什么方案？shell脚本还是api的方式？ 各位大佬，开启增量checkpoint 情况下，这个state size 是总的checkpoint 大小，还是增量上传的大小？ 想用状态表作为子表 外面嵌套窗口 如何实现呢 因为状态表group by之后 ctime会失去时间属性,有哪位大佬知道的？ 你们有试过在同样的3台机器上部署两套kafka吗？ 大家有没有比较好的sql解析 组件（支持嵌套sql）? richmapfuntion的open/close方法，和处理数据的map方法，是在同一个线程，还是不同线程调用的？ flink on yarn 提交 参数 -p 20 -yn 5 -ys 3 ，我不是只启动了5个container么？ Flink的乱序问题怎么解决? 我对数据流先进行了keyBy,print的时候是有数据的,一旦进行了timeWindow滑动窗口就没有数据了,请问是什么情况呢? 搭建flinksql平台的时候，怎么处理udf的呀? 怎么查看sentry元数据里哪些角色有哪些权限？ 用java api写的kafka consumer能消费到的消息，但是Flink消费不到，这是为啥? 我state大小如果为2G左右 每次checkpoint会不会有压力? link-table中的udaf能用deltaTrigger么？ flink1.7.2，场景是一分钟为窗口计算每分钟传感器的最高温度，同时计算当前分钟与上一分钟最高温 001 Flink集群支持kerberos认证吗？也就是说flink客户端需要向Flink集群进行kerberos认证，认证通过之后客户端才能提交作业到Flink集群运行002 Flink支持多租户吗？ 如果要对客户端提交作业到flink进行访问控制，你们有类似的这种使用场景吗？ flink可以同时读取多个topic的数据吗？ Flink能够做实时ETL（oracle端到oracle端或者多端）么？ Flink是否适合普通的关系型数据库呢？ Flink是否适合普通的关系型数据库呢？ 流窗口关联mysql中的维度表大佬们都是怎么做的啊? 怎么保证整个链路的exactly one episode精准一次，从source 到flink到sink? 在SQL的TUMBLE窗口的统计中，如果没数据进来的，如何让他也定期执行，比如进行count计算，让他输出0？ new FlinkKafkaConsumer010[String]("PREWARNING",new JSONKeyValueDeserializationSchema(true), kafkaProps).setStartFromGroupOffsets() ) 我这样new 它说要我传个KeyedDeserializationSchema接口进去 flink里面broadcast state想定时reload怎么做？我用kafka里的stream flink独立模式高可用搭建必需要hadoop吗？ 有人用增量cleanupIncrementally的方式来清理状态的嘛，感觉性能很差。 flink sink to hbase继承 RichOutputFormat运行就报错 kafka 只有低级 api 才拿得到 offset 吗？ 有个问题咨询下大家，我的flinksql中有一些参数是要从mysql中获取的，比如我flink的sql是select * from aa where cc=?,这个问号的参数需要从mysql中获取，我用普通的jdbc进行连接可以获的，但是有一个问题，就是我mysql的数据改了之后必须重启flink程序才能解决这个问题，但这肯定不符合要求，请问大家有什么好的办法吗？ flink里怎样实现多表关联制作宽表 flink写es，因为半夜es集群做路由，导致写入容易失败，会引起source的反压，然后导致checkpoint超时任务卡死，请问有没有办法在下游es处理慢的时候暂停上游的导入来缓解反压？ flink 写parquet 文件，使用StreamingFileSink streamingFileSink = StreamingFileSink.forBulkFormat( new Path(path), ParquetAvroWriters.forReflectRecord(BuyerviewcarListLog.class)). withBucketAssigner(bucketAssigner).build(); 报错 java.lang.UnsupportedOperationException: Recoverable writers on Hadoop are only supported for HDFS and for Hadoop version 2.7 or newer 1.7.2 NoWindowInnerJoin这个实现，我看实现了CleanupState可更新过期时间删除当前key状态的接口，是不是这个1.7.2版本即使有个流的key一直没有被匹配到他的状态也会被清理掉，就不会存在内存泄漏的问题了？ flink1.7.2 想在Table的UDAF中使用State，但是发现UDAF的open函数的FunctionContext中对于RuntimeContext是一个private，无法使用，大佬，如何在Table的UDAF中使用State啊？ Flink有什么性能测试工具吗？ 项目里用到了了KafkaTableSourceSinkFactory和JDBCTableSourceSinkFactory。maven打包后，META-INF里只会保留第一个 标签的org.apache.flink.table.factories.TableFactory内容。然后执行时就会有找不到合适factory的报错，请问有什么解决办法吗？ 为什么这个这段逻辑 debug的时候 是直接跳过的 各位大佬，以天为单位的窗口有没有遇到过在八点钟的时候会生成一条昨天的记录? 想问一下，我要做一个规则引擎，需要动态改变规则，如何在flink里面执行？ flink-1.9.1/bin/yarn-session.sh: line 32: construc 我要用sql做一个规则引擎，需要动态改变规则，如何在flink里面执行？ 我要用sql做一个规则引擎，需要动态改变规则，如何在flink里面执行？ 一般公司的flink job有没有进程进行守护？有专门的工具或者是自己写脚本？这种情况针对flink kafka能不能通过java获取topic的消息所占空间大小？ Flink container was removed这个咋解决的。我有时候没有数据的时候也出现这 大家有没有这种场景，数据从binlog消费，这个信息是订单信息，同一个订单id，会有不同状态的变更 问大家个Hive问题，新建的hive外部分区表， 怎么把HDFS数据一次性全部导入hive里 ？ flink里面的broadcast state值，会出现broad流的数据还没put进mapstat Flink SQL DDL 创建表时，如何定义字段的类型为proctime? 请问下窗口计算能对历史数据进行处理吗？比如kafka里的写数据没停，窗口计算的应用停掉一段时间再开起 请问下，想统计未退费的订单数量，如果一个订单退费了（发过来一个update流），flink能做到对结果进行-1吗，这样的需求sql支持吗? 使用Flink sql时,对table使用了group by操作。然后将结果转换为流时是不是只能使用的toRetractStream方法不能使用toAppendStream方法。 百亿数据实时去重，有哪位同学实践过吗？ 你们的去重容许有误差？因为bloom filter其实只能给出【肯定不存在】和【可能存在】两种结果。对于可能存在这种结果，你们会认为是同一条记录？ 我就运行了一个自带的示例，一运行就报错然后web页面就崩了 flink定时加载外部数据有人做过吗？ NoSuchMethodError: org.apache.flink.api.java.Utils.resolveFactory(Ljava/lang/ThreadLocal;Ljava/lang/Object;)Ljava/util/Optional 各位知道这个是那个包吗？ flink 可以把大量数据写入mysql吗？比如10g flink sql 解析复杂的json可以吗？ 在页面上写规则，用flink执行，怎么传递给flink？ 使用cep时，如何动态添加规则？ 如何基于flink 实现两个很大的数据集的交集 并集 差集？ flink的应用场景是？除了实时 各位好，请教一下，滑动窗口，每次滑动都全量输出结果，外部存储系统压力大，是否有办法，只输出变化的key？ RichSinkFunction close只有任务结束时候才会去调用，但是数据库连接一直拿着，最后成了数据库连接超时了，大佬们有什么好的建议去处理吗？？ 为啥我的自定义函数注册，然后sql中使用不了？ 请问一下各位老师，flink flapmap 中的collector.collect经常出现Buffer pool is destroyed可能是什么原因呢？ 用asyncIO比直接在map里实现读hbase还慢，在和hbase交互这块儿，每个算子都加了时间统计 请教一下，在yarn上运行，会找不到 org.apache.flink.streaming.util 请问下大佬，flink1.7.2对于sql的支持是不是不怎么好啊 ，跑的数据一大就会报错。 各位大佬，都用什么来监控flink集群？ flink 有那种把多条消息聚合成一条的操作吗，比如说每五十条聚合成一条 如何可以让checkpoint 跳过对齐呢? 请问 阿里云实时计算（Blink）支持这4个源数据表吗？DataHub Kafka MQ MaxCompute？ 为啥checkpoint时间会越来越长，请问哪位大佬知道是因为啥呢？ 请问Flink的最大并行度跟kafka partition数量有关系吗? source的并行度应该最好是跟partition数量一致吧，那剩下的算子并行度呢？ Flink有 MLIB库吗，为什么1.9中没有了啊？ 请教一下，有没有flink ui的文章呢？在这块内存配置，我给 TM 配置的内存只有 4096 M，但是这里为什么对不上呢？请问哪里可以看 TM 内存使用了多少呢？ 请教个问题，fink RichSinkFunction的invoke方法是什么时候被调用的？ 请教一下，flink的window的触发条件 watermark 小于 window 的 end_time。这个 watermark 为什么是针对所有数据的呢？没有设计为一个 key 一个 watermark 呢？ 就比如说有 key1、key2、key3，有3个 watermark，有 3个 window interval不支持left join那怎么可以实现把窗口内左表的数据也写到下游呢？ 各位 1、sink如何只得到最终的结果而不是也输出过程结果 ；2、不同的运算如何不借助外部系统的存储作为另外一个运算的source 请教各位一个问题，flink中设置什么配置可以取消Generic这个泛型，如图报错： 有大佬在吗，线上遇到个问题，但是明明内存还有200多G，然后呢任务cancel不了，台也取消不了程序 flink遇到The assigned slot container_1540803405745_0094_01_000008_1 was removed. 有木有大佬遇到过。在flink on yarn上跑 这个报错是什么意思呢?我使用滑动窗口的时候出现报错 flink 双流union状态过期不清理有遇到的吗? 大家有没有这种场景，数据从binlog消费，这个信息是订单信息，同一个订单id，会有不同状态的变更，如果订单表与商品明细join查询，就会出现n条重复数据，这样数据就不准了，flink 这块有没有比较好的实战经验的。 大佬们、有没有人遇到过使用一分钟的TumblingEventTimeWindows，但是没有按时触发窗口、而是一直等到下一条消息进来之后才会把这个窗口的数据发送出去的？ flink 有办法 读取 pytorch的 模型文件吗？ 大佬们、有没有人遇到过使用一分钟的TumblingEventTimeWindows，但是没有按时触发窗口、而是一直等到下一条消息进来之后才会把这个窗口的数据发送出去的？ flink timestamp转换为date类型，有什么函数吗 flink 写入mysql 很长一段时间没有写入，报错怎么解决呢? flink 有办法 读取 pytorch的 模型文件吗？ 有没有大佬知道实时报表怎么做？就是统计的结果要实时更新，热数据。 刚接触flink 1.9 求问flink run脚本中怎么没有相关提交到yarn的命令了 请教一下，flink里怎么实现batch sink的操作而不导致数据丢失

本文总结了常见的 Linux 内核参数及相关问题。修改内核参数前，您需要： 从实际需要出发，最好有相关数据的支撑，若您的业务没有受到影响不建议调整内核参数。 了解每一个参数的具体作用，并且同类型或版本操作系统下内核参数可能有所不同。 备份 ECS 实例中的重要数据。参阅文档 创建快照。 Linux 常用内核网络参数 参数 描述 net.core.rmem_default 默认的 TCP 数据接收窗口大小（字节）。 net.core.rmem_max 最大的 TCP 数据接收窗口（字节）。 net.core.wmem_default 默认的 TCP 数据发送窗口大小（字节）。 net.core.wmem_max 最大的 TCP 数据发送窗口（字节）。 net.core.netdev_max_backlog 在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。 net.core.somaxconn 定义了系统中每一个端口最大的监听队列的长度，这是个全局的参数。 net.core.optmem_max 表示每个套接字所允许的最大缓冲区的大小。 net.ipv4.tcp_mem 确定 TCP 栈应该如何反映内存使用，每个值的单位都是内存页（通常是 4KB）第一个值是内存使用的下限；第二个值是内存压力模式开始对缓冲区使用应用压力的上限；第三个值是内存使用的上限。在这个层次上可以将报文丢弃，从而减少对内存的使用。对于较大的 BDP 可以增大这些值（注意：其单位是内存页而不是字节）。 net.ipv4.tcp_rmem 为自动调优定义 socket 使用的内存。第一个值是为 socket 接收缓冲区分配的最少字节数；第二个值是默认值（该值会被 rmem_default 覆盖），缓冲区在系统负载不重的情况下可以增长到这个值；第三个值是接收缓冲区空间的最大字节数（该值会被 rmem_max 覆盖）。 net.ipv4.tcp_wmem 为自动调优定义 socket 使用的内存。第一个值是为 socket 发送缓冲区分配的最少字节数；第二个值是默认值（该值会被 wmem_default 覆盖），缓冲区在系统负载不重的情况下可以增长到这个值；第三个值是发送缓冲区空间的最大字节数（该值会被 wmem_max 覆盖）。 net.ipv4.tcp_keepalive_time TCP 发送 keepalive 探测消息的间隔时间（秒），用于确认 TCP 连接是否有效。 net.ipv4.tcp_keepalive_intvl 探测消息未获得响应时，重发该消息的间隔时间（秒）。 net.ipv4.tcp_keepalive_probes 在认定 TCP 连接失效之前，最多发送多少个 keepalive 探测消息。 net.ipv4.tcp_sack 启用有选择的应答（1 表示启用），通过有选择地应答乱序接收到的报文来提高性能，让发送者只发送丢失的报文段，（对于广域网通信来说）这个选项应该启用，但是会增加对 CPU 的占用。 net.ipv4.tcp_fack 启用转发应答，可以进行有选择应答（SACK）从而减少拥塞情况的发生，这个选项也应该启用。 net.ipv4.tcp_timestamps TCP 时间戳（会在 TCP 包头增加 12 B），以一种比重发超时更精确的方法（参考 RFC 1323）来启用对 RTT 的计算，为实现更好的性能应该启用这个选项。 net.ipv4.tcp_window_scaling 启用 RFC 1323 定义的 window scaling，要支持超过 64KB 的 TCP 窗口，必须启用该值（1 表示启用），TCP 窗口最大至 1GB，TCP 连接双方都启用时才生效。 net.ipv4.tcp_syncookies 表示是否打开 TCP 同步标签（syncookie），内核必须打开了 CONFIG_SYN_COOKIES 项进行编译，同步标签可以防止一个套接字在有过多试图连接到达时引起过载。默认值 0 表示关闭。 net.ipv4.tcp_tw_reuse 表示是否允许将处于 TIME-WAIT 状态的 socket （TIME-WAIT 的端口）用于新的 TCP 连接。 net.ipv4.tcp_tw_recycle 能够更快地回收 TIME-WAIT 套接字。 net.ipv4.tcp_fin_timeout 对于本端断开的 socket 连接，TCP 保持在 FIN-WAIT-2 状态的时间（秒）。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。 net.ipv4.ip_local_port_range 表示 TCP/UDP 协议允许使用的本地端口号。 net.ipv4.tcp_max_syn_backlog 对于还未获得对方确认的连接请求，可保存在队列中的最大数目。如果服务器经常出现过载，可以尝试增加这个数字。默认为 1024。 net.ipv4.tcp_low_latency 允许 TCP/IP 栈适应在高吞吐量情况下低延时的情况，这个选项应该禁用。 net.ipv4.tcp_westwood 启用发送者端的拥塞控制算法，它可以维护对吞吐量的评估，并试图对带宽的整体利用情况进行优化，对于 WAN 通信来说应该启用这个选项。 net.ipv4.tcp_bic 为快速长距离网络启用 Binary Increase Congestion，这样可以更好地利用以 GB 速度进行操作的链接，对于 WAN 通信应该启用这个选项。 net.ipv4.tcp_max_tw_buckets 该参数设置系统的 TIME_WAIT 的数量，如果超过默认值则会被立即清除。默认为 180000。 net.ipv4.tcp_synack_retries 指明了处于 SYN_RECV 状态时重传 SYN+ACK 包的次数。 net.ipv4.tcp_abort_on_overflow 设置改参数为 1 时，当系统在短时间内收到了大量的请求，而相关的应用程序未能处理时，就会发送 Reset 包直接终止这些链接。建议通过优化应用程序的效率来提高处理能力，而不是简单地 Reset。默认值： 0 net.ipv4.route.max_size 内核所允许的最大路由数目。 net.ipv4.ip_forward 接口间转发报文。 net.ipv4.ip_default_ttl 报文可以经过的最大跳数。 net.netfilter.nf_conntrack_tcp_timeout_established 让 iptables 对于已建立的连接，在设置时间内若没有活动，那么则清除掉。 net.netfilter.nf_conntrack_max 哈希表项最大值。 查看和修改 Linux 实例内核参数 方法一、通过 /proc/sys/ 目录 /proc/sys/ 目录是 Linux 内核在启动后生成的伪目录，其目录下的 net 文件夹中存放了当前系统中生效的所有内核参数、目录树结构与参数的完整名称相关，如 net.ipv4.tcp_tw_recycle，它对应的文件是 /proc/sys/net/ipv4/tcp_tw_recycle，文件的内容就是参数值。 查看内核参数：使用 cat 查看对应文件的内容，例如执行命令 cat /proc/sys/net/ipv4/tcp_tw_recycle 查看 net.ipv4.tcp_tw_recycle 的值。 修改内核参数：使用 echo 修改内核参数对应的文件，例如执行命令 echo "0" > /proc/sys/net/ipv4/tcp_tw_recycle 将 net.ipv4.tcp_tw_recycle 的值修改为 0。 注意：方法一修改的参数值仅在当次运行中生效，系统重启后会回滚历史值，一般用于临时性的验证修改的效果。若需要永久性的修改，请参阅方法二。 方法二、通过 sysctl.conf 文件 查看内核参数：执行命令 sysctl -a 查看当前系统中生效的所有参数，如下所示： net.ipv4.tcp_app_win = 31 net.ipv4.tcp_adv_win_scale = 2 net.ipv4.tcp_tw_reuse = 0 net.ipv4.tcp_frto = 2 net.ipv4.tcp_frto_response = 0 net.ipv4.tcp_low_latency = 0 net.ipv4.tcp_no_metrics_save = 0 net.ipv4.tcp_moderate_rcvbuf = 1 net.ipv4.tcp_tso_win_divisor = 3 net.ipv4.tcp_congestion_control = cubic net.ipv4.tcp_abc = 0 net.ipv4.tcp_mtu_probing = 0 net.ipv4.tcp_base_mss = 512 net.ipv4.tcp_workaround_signed_windows = 0 net.ipv4.tcp_challenge_ack_limit = 1000 net.ipv4.tcp_limit_output_bytes = 262144 net.ipv4.tcp_dma_copybreak = 4096 net.ipv4.tcp_slow_start_after_idle = 1 net.ipv4.cipso_cache_enable = 1 net.ipv4.cipso_cache_bucket_size = 10 net.ipv4.cipso_rbm_optfmt = 0 net.ipv4.cipso_rbm_strictvalid = 1 修改内核参数： 执行命令   /sbin/sysctl -w kernel.domainname="example.com"  来修改指定的参数值，如 sysctl -w net.ipv4.tcp_tw_recycle="0" 执行命令   vi /etc/sysctl.conf  修改   /etc/sysctl.conf  文件中的参数。 执行命令   /sbin/sysctl -p  使配置生效。 Linux 网络相关内核参数引发的常见问题及处理 问题现象 原因分析 解决方案 无法在本地网络环境通过 SSH 连接 ECS Linux 实例，或者访问该 Linux 实例上的 HTTP 业务出现异常。Telnet 测试会被 reset。 如果您的本地网络是 NAT 共享方式上网，该问题可能是由于本地 NAT 环境和目标 Linux 相关内核参数配置不匹配导致。尝试通过修改目标 Linux 实例内核参数来解决问题：1. 远程连接目标 Linux 实例；2. 查看当前配置： cat /proc/sys/net/ipv4/tcp_tw_recyclecat /proc/sys/net/ipv4/tcp_timestamps 查看上述两个配置的值是不是 0，如果为 1的话，NAT 环境下的请求可能会导致上述问题。 通过如下方式将上述参数值修改为 0：1. 执行命令 vi /etc/sysctl.conf。2. 添加如下内容：net.ipv4.tcp_tw_recycle=0net.ipv4.tcp_timestamps=0。3. 输入指令 # sysctl -p 使配置生效。4. 重新 SSH 登录实例或者业务访问测试。 服务端 A 与 客户端 B 建立了 TCP 连接，之后服务端 A 主动断开了连接，但是在客户端 B 上仍然看到连接是建立的。示例见图一，图二。 通常是由于修改了服务端内核参数 net.ipv4.tcp_fin_timeout 默认设置所致。 1. 执行命令 vi /etc/sysctl.conf，修改配置：net.ipv4.tcp_fin_timeout=30。2. 执行命令 # sysctl -p 使配置生效。 通过 netstat 或 ss 可以看到大量处于 TIME_WAIT 状态的连接。 通过 netstat -n | awk ‘/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}’ 查看 TIME_WAIT 数量。 1. 执行命令 vi /etc/sysctl.conf，修改或加入以下内容： net . ipv4 . tcp_syncookies = 1 net . ipv4 . tcp_tw_reuse = 1 net . ipv4 . tcp_tw_recycle = 1 net . ipv4 . tcp_fin_timeout = 30 2. 执行命令 /sbin/sysctl -p  使配置生效。 云服务器上出现大量 CLOSE_WAIT 状态的连接数。 根据实例上的业务量来判断 CLOSE_WAIT 数量是否超出了正常的范围。TCP 连接断开时需要进行四次挥手，TCP 连接的两端都可以发起关闭连接的请求，若对端发起了关闭连接，但本地没有进行后续的关闭连接操作，那么该链接就会处于 CLOSE_WAIT 状态。虽然该链接已经处于半开状态，但是已经无法和对端通信，需要及时的释放该链接。建议从业务层面及时判断某个连接是否已经被对端关闭，即在程序逻辑中对连接及时进行关闭检查。 通过命令 netstat -an|grep CLOSE_WAIT|wc -l 查看当前实例上处于 CLOSE_WAIT 状态的连接数。Java 语言：1. 通过 read 方法来判断 I/O 。当 read 方法返回 -1 时则表示已经到达末尾。2. 通过 close 方法关闭该链接。C 语言：1. 检查 read 的返回值，若是 0 则可以关闭该连接，若小于 0 则查看一下 errno，若不是 AGAIN 则同样可以关闭连接。 ECS Linux FIN_WAIT2 状态的 TCP 链接过多。 HTTP 服务中，SERVER 由于某种原因关闭连接，如 KEEPALIVE 的超时。这样，作为主动关闭的 SERVER 一方就会进入 FIN_WAIT2 状态。但 TCP/IP 协议栈中，FIN_WAIT2 状态是没有超时的（不像 TIME_WAIT 状态），如果 Client 不关闭，FIN_WAIT_2 状态将保持到系统重启，越来越多的 FIN_WAIT_2 状态会致使内核 Crash。 1. 执行命令 vi /etc/sysctl.conf，修改或加入以下内容： net . ipv4 . tcp_syncookies = 1 net . ipv4 . tcp_fin_timeout = 30 net . ipv4 . tcp_max_syn_backlog = 8192 net . ipv4 . tcp_max_tw_buckets = 5000 2. 执行命令 # sysctl -p 使配置生效。 查询服务器 /var/log/message 日志，发现全部是类似如下 kernel: TCP: time wait bucket table overflowt 的报错信息，报错提示 TCP time wait 溢出，见图三。 TCP 连接使用很高，容易超出限制。见图四。 1. 执行命令 netstat -anp |grep tcp |wc -l统计 TCP 连接数。2. 对比 /etc/sysctl.conf 配置文件的 net.ipv4.tcp_max_tw_buckets 最大值，看是否有超出情况。3. 执行命令 vi /etc/sysctl.conf，查询 net.ipv4.tcp_max_tw_buckets 参数。如果确认连接使用很高，容易超出限制。4. 调高参数 net.ipv4.tcp_max_tw_buckets，扩大限制。5. 执行命令 # sysctl -p 使配置生效。 ECS Linux 实例出现间歇性丢包的情况，通过 tracert， mtr 等手段排查，外部网络未见异常。同时，如下图所示，在系统日志中重复出现大量kernel nf_conntrack: table full, dropping packet.错误信息。见图五。 ip_conntrack 是 Linux 系统内 NAT 的一个跟踪连接条目的模块。ip_conntrack 模块会使用一个哈希表记录 TCP 通讯协议的 established connection 记录，当哈希表满了的时候，会导致 nf_conntrack: table full, dropping packet 错误。需要通过修改内核参数来调整 ip_conntrack 限制。 Centos 5.x 系统1. 使用管理终端登录实例。2. 执行命令 # vi /etc/sysctl.conf 编辑系统内核配置。3. 修改哈希表项最大值参数：net.ipv4.netfilter.ip_conntrack_max = 655350。4. 修改超时时间参数：net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 1200，默认情况下 timeout 是5天（432000秒）。5. 执行命令 # sysctl -p 使配置生效。Centos 6.x 及以上系统：1. 使用管理终端登录实例。2. 执行命令 # vi /etc/sysctl.conf 编辑系统内核配置。3. 修改哈希表项最大值参数：net.netfilter.nf_conntrack_max = 655350。4. 修改超时时间参数：net.netfilter.nf_conntrack_tcp_timeout_established = 1200，默认情况下 timeout 是5天（432000秒）。5. 执行命令 # sysctl -p 使配置生效。 客户端做了 NAT 后无法访问 ECS、RDS，包括通过 SNAT VPC 访问外网的 ECS 。无法访问连接其他 ECS 或 RDS 等云产品，抓包检测发现远端对客户端发送的 SYN 包没有响应。 若远端服务器同时开启 net.ipv4.tcp_tw_recycle 和 net.ipv4.tcp_timestamps，即参数取值为 1 时，服务器会检查每一个报文的时间戳（Timestamp），若 Timestamp 不是递增的关系，则不做处理。做了 NAT 后，服务器看到来自不同的客户端的 IP 相似，但 NAT 前每一台客户端的时间可能会有偏差，在服务器上就会看到 Timestamp 不是递增的情况。 - 远端服务器为 ECS：修改参数 net.ipv4.tcp_tw_recycle 为 0。- 远端服务器为 RDS 等 PaaS 服务：RDS 无法直接修改内核参数，需要在客户端上修改参数 net.ipv4.tcp_tw_recycle 和 net.ipv4.tcp_timestamps 为 0。 参考链接 Linux man-pages kernel/git/torvalds/linux.git_proc kernel/git/torvalds/linux.git_proc_net_tcp kernel/git/torvalds/linux.git_ip-sysctl kernel/git/torvalds/linux.git_netfilter-sysctl kernel/git/torvalds/linux.git_nf_conntrack-sysctl 图一： 客户端 B TCP 连接 图二： 客户端 A TCP 连接 图三： 报错提示 TCP time wait 溢出 图四： 查询 net.ipv4.tcp_max_tw_buckets 参数 图五： ECS Linux 实例间歇性丢包

　　算法，数据结构是关键，另外还有组合数学，特别是集合与图论，概率论也重要。推荐买一本《算法导论》，那本书行，看起来超爽。。。基本掌握语法还不行啊，语法的超熟练掌握，不然出了错误很难调试的。。。最重要的是超牛皮的头脑啦，分析能力，逻辑推理能力很重要。ACM很好玩啦，祝你成功。。。 　　acm是3人一组的，以学校为单位报名的，也就是说要得到学校同意，还要有2个一起搞的。其实可能是你不知道你们学校搞acm的地方，建议你好好询问下你们学校管科技创新方面的人。建议你找几个兴趣相同的一起做，互相探讨效果好多了，团队合作也是acm要求的3大能力之一。 　　数据结构远远不够的，建议你看算法导论，黑书，oj的话个人觉得还是poj好，有水题有好题，而且做的人多，要解题报告什么的也好找。我们就是一些做acm的学生一起搞，也没老师，这样肯定能行的。 　　基础的话是语言，然后数据结构，然后算法。 　　ACM有三个方向：算法，数学，实现 　　要求三种能力：英文，自学，团队协作 　　简单的说，你要能读懂英文的题意描述，要有一门acm能使用的编程语言，要会数据结构，有一点数学基础，一点编程方面天赋，要有兴趣和毅力（最重要），就具有做ACM的基本条件了。 　　做acm我推荐c，c++也可以，java在某些情况下好用，但是大多数情况的效率和代码量都不大好，所以建议主用c++，有些题目用java 　　还有什么问题，可以问我啊。 　　不好意思，没见过用java描述的acm书籍，大多数是用伪命令，其他有的用的c，c++，老一些的用pascal。java只是用来做高精度的一些题的，个人觉得不用专门看这方面的书，java的基本部分学好就够用了。所以我还是推荐主用c++，在高精度和个别题再用java。你可以找找java描述的算法设计与分析，这个好像有 　　数据结构：C语言版 清华大学出版社 严蔚敏 《数据结构》 　　算法：清华大学出版社 王晓东 《算法设计与分析》 　　麻省理工大学 中译本：机械工业出版社 《算法导论》 　　基本上这三本书就已经足够了，建议一般水平的人先不要看算法导论，待另外两本书看的差不多的时候，再看算法导论加深理解。 　　另外还有很多针对性更强的书籍，不过针对性太强，这里就不多介绍了。 　　以上一些都是些算法方面的书，最好的方式就是做题与看书相结合，很多在线做题的网站，PKU，ZOJ很多，推荐PKU，题目比较多，参与的人比较多。做一段时间的题，然后看书，研究算法，再做题，这样进步比较快。 　　还有关于ACM竞赛，我有自己的一点话说。 　　首先说下ACM/ICPC是个团队项目，最后的参赛名额是按照学校为单位的，所以找到志同道合的队友和学校的支持是很重要的。 　　刚刚接触信息学领域的同学往往存在很多困惑，不知道从何入手学习，在这篇文章里，我希望能将自己不多的经验与大家分享，希望对各位有所帮助。 　　一、语言是最重要的基本功 　　无论侧重于什么方面，只要是通过计算机程序去最终实现的竞赛，语言都是大家要过的第一道关。亚洲赛区的比赛支持的语言包括C/C++与JAVA。笔者首先说说JAVA，众所周知，作为面向对象的王牌语言，JAVA在大型工程的组织与安全性方面有着自己独特的优势，但是对于信息学比赛的具体场合，JAVA则显得不那么合适，它对于输入输出流的操作相比于C++要繁杂很多，更为重要的是JAVA程序的运行速度要比C++慢10倍以上，而竞赛中对于JAVA程序的运行时限却往往得不到同等比例的放宽，这无疑对算法设计提出了更高的要求，是相当不利的。其实，笔者并不主张大家在这种场合过多地运用面向对象的程序设计思维，因为对于小程序来说这不旦需要花费更多的时间去编写代码，也会降低程序的执行效率。 　　接着说C和C++。许多现在参加讲座的同学还在上大一，C的基础知识刚刚学完，还没有接触过C++，其实在赛场上使用纯C的选手还是大有人在的，它们主要是看重了纯C在效率上的优势，所以这部分同学如果时间有限，并不需要急着去学习新的语言，只要提高了自己在算法设计上的造诣，纯C一样能发挥巨大的威力。 　　而C++相对于C，在输入输出流上的封装大大方便了我们的操作，同时降低了出错的可能性，并且能够很好地实现标准流与文件流的切换，方便了调试的工作。如果有些同学比较在意这点，可以尝试C和C++的混编，毕竟仅仅学习C++的流操作还是不花什么时间的。 　　C++的另一个支持来源于标准模版库（STL），库中提供的对于基本数据结构的统一接口操作和基本算法的实现可以缩减我们编写代码的长度，这可以节省一些时间。但是，与此相对的，使用STL要在效率上做出一些牺牲，对于输入规模很大的题目，有时候必须放弃STL，这意味着我们不能存在“有了STL就可以不去管基本算法的实现”的想法；另外，熟练和恰当地使用STL必须经过一定时间的积累，准确地了解各种操作的时间复杂度，切忌对STL中不熟悉的部分滥用，因为这其中蕴涵着许多初学者不易发现的陷阱。 　　通过以上的分析，我们可以看出仅就信息学竞赛而言，对语言的掌握并不要求十分全面，但是对于经常用到的部分，必须十分熟练，不允许有半点不清楚的地方，下面我举个真实的例子来说明这个道理——即使是一点很细微的语言障碍，都有可能酿成错误： 　　在去年清华的赛区上，有一个队在做F题的时候使用了cout和printf的混合输出，由于一个带缓冲一个不带，所以输出一长就混乱了。只是因为当时judge team中负责F题的人眼睛尖，看出答案没错只是顺序不对（答案有一页多，是所有题目中最长的一个输出），又看了看程序发现只是输出问题就给了个Presentation error（格式错）。如果审题的人不是这样而是直接给一个 Wrong Answer，相信这个队是很难查到自己错在什么地方的。 　　现在我们转入第二个方面的讨论，基础学科知识的积累。 　　二、以数学为主的基础知识十分重要 　　虽然被定性为程序设计竞赛，但是参赛选手所遇到的问题更多的是没有解决问题的思路，而不是有了思路却死活不能实现，这就是平时积累的基础知识不够。今年World Final的总冠军是波兰华沙大学，其成员出自于数学系而非计算机系，这就是一个鲜活的例子。竞赛中对于基础学科的涉及主要集中于数学，此外对于物理、电路等等也可能有一定应用，但是不多。因此，大一的同学也不必为自己还没学数据结构而感到不知从何入手提高，把数学捡起来吧。下面我来谈谈在竞赛中应用的数学的主要分支。 　　1、离散数学——作为计算机学科的基础，离散数学是竞赛中涉及最多的数学分支，其重中之重又在于图论和组合数学，尤其是图论。 　　图论之所以运用最多是因为它的变化最多，而且可以轻易地结合基本数据结构和许多算法的基本思想，较多用到的知识包括连通性判断、DFS和BFS，关节点和关键路径、欧拉回路、最小生成树、最短路径、二部图匹配和网络流等等。虽然这部分的比重很大，但是往往也是竞赛中的难题所在，如果有初学者对于这部分的某些具体内容暂时感到力不从心，也不必着急，可以慢慢积累。 　　竞赛中设计的组合计数问题大都需要用组合数学来解决，组合数学中的知识相比于图论要简单一些，很多知识对于小学上过奥校的同学来说已经十分熟悉，但是也有一些部分需要先对代数结构中的群论有初步了解才能进行学习。组合数学在竞赛中很少以难题的形式出现，但是如果积累不够，任何一道这方面的题目却都有可能成为难题。 　　2、数论——以素数判断和同余为模型构造出来的题目往往需要较多的数论知识来解决，这部分在竞赛中的比重并不大，但只要来上一道，也足以使知识不足的人冥思苦想上一阵时间。素数判断和同余最常见的是在以密码学为背景的题目中出现，在运用密码学常识确定大概的过程之后，核心算法往往要涉及数论的内容。 　　3、计算几何——计算几何相比于其它部分来说是比较独立的，就是说它和其它的知识点很少有过多的结合，较常用到的部分包括——线段相交的判断、多边形面积的计算、内点外点的判断、凸包等等。计算几何的题目难度不会很大，但也永远不会成为最弱的题。 　　4、线性代数——对线性代数的应用都是围绕矩阵展开的，一些表面上是模拟的题目往往可以借助于矩阵来找到更好的算法。 　　5、概率论——竞赛是以黑箱来判卷的，这就是说你几乎不能动使用概率算法的念头，但这也并不是说概率就没有用。关于这一点，只有通过一定的练习才能体会。 　　6、初等数学与解析几何——这主要就是中学的知识了，用的不多，但是至少比高等数学多，我觉得熟悉一下数学手册上的相关内容，至少要知道在哪儿能查到，还是必要的。 　　7、高等数学——纯粹运用高等数学来解决的题目我接触的只有一道，但是一些题目的叙述背景往往需要和这部分有一定联系，掌握得牢固一些总归没有坏处。 　　以上就是竞赛所涉及的数学领域，可以说范围是相当广的。我认识的许多人去搞信息学的竞赛就是为了逼着自己多学一点数学，因为数学是一切一切的基础。 　　三、数据结构与算法是真正的核心 　　虽然数学十分十分重要，但是如果让三个只会数学的人参加比赛，我相信多数情况下会比三个只会数据结构与算法的人得到更为悲惨的结局。 　　先说说数据结构。掌握队列、堆栈和图的基本表达与操作是必需的，至于树，我个人觉得需要建树的问题有但是并不多。（但是树往往是很重要的分析工具）除此之外，排序和查找并不需要对所有方式都能很熟练的掌握，但你必须保证自己对于各种情况都有一个在时间复杂度上满足最低要求的解决方案。说到时间复杂度，就又该说说哈希表了，竞赛时对时间的限制远远多于对空间的限制，这要求大家尽快掌握“以空间换时间”的原则策略，能用哈希表来存储的数据一定不要到时候再去查找，如果实在不能建哈希表，再看看能否建二叉查找树等等——这都是争取时间的策略，掌握这些技巧需要大家对数据结构尤其是算法复杂度有比较全面的理性和感性认识。 　　接着说说算法。算法中最基本和常用的是搜索，主要是回溯和分支限界法的使用。这里要说的是，有些初学者在学习这些搜索基本算法是不太注意剪枝，这是十分不可取的，因为所有搜索的题目给你的测试用例都不会有很大的规模，你往往察觉不出程序运行的时间问题，但是真正的测试数据一定能过滤出那些没有剪枝的算法。实际上参赛选手基本上都会使用常用的搜索算法，题目的区分度往往就是建立在诸如剪枝之类的优化上了。 　　常用算法中的另一类是以“相似或相同子问题”为核心的，包括递推、递归、贪心法和动态规划。这其中比较难于掌握的就是动态规划，如何抽象出重复的子问题是很多题目的难点所在，笔者建议初学者仔细理解图论中一些以动态规划为基本思想所建立起来的基本算法（比如Floyd-Warshall算法），并且多阅读一些定理的证明，这虽然不能有什么直接的帮助，但是长期坚持就会对思维很有帮助。 　　四、团队配合 　　通过以上的介绍大家也可以看出，信息学竞赛对于知识面覆盖的非常广，想凭一己之力全部消化这些东西实在是相当困难的，这就要求我们尽可能地发挥团队协作的精神。同组成员之间的熟练配合和默契的形成需要时间，具体的情况因成员的组成不同而不同，这里我就不再多说了。 　　五、练习、练习、再练习 　　知识的积累固然重要，但是信息学终究不是看出来的，而是练出来的，这是多少前人最深的一点体会，只有通过具体题目的分析和实践，才能真正掌握数学的使用和算法的应用，并在不断的练习中增加编程经验和技巧，提高对时间复杂度的感性认识，优化时间的分配，加强团队的配合。总之，在这里光有纸上谈兵是绝对不行的，必须要通过实战来锻炼自己。 　　大家一定要问，我们去哪里找题做，又如何检验程序是否正确呢。这大可不必担心，现在已经有了很多网上做题的站点，这些站点提供了大量的题库并支持在线判卷，你只需要把程序源码提交上去，马上就可以知道自己的程序是否正确，运行所使用的时间以及消耗的内存等等状况。下面我给大家推荐几个站点，笔者不建议大家在所有这些站点上做题，选择一个就可以了，因为每个站点的题都有一定的难易比例，系统地做一套题库可以使你对各种难度、各种类型的题都有所认识。 　　1、Ural： 　　Ural是中国学生对俄罗斯的Ural州立大学的简称 ，那里设立了一个Ural Online Problem Set，并且支持Online Judge。Ural的不少题目算法性和趣闻性都很强，得到了国内广大学生的厚爱。根据“信息学初学者之家”网站的统计，Ural的题目类型大概呈如下的分布： 　　题型 　　搜索 　　动态规划 　　贪心 　　构造 　　图论 　　计算几何 　　纯数学问题 　　数据结构 　　其它 　　所占比例 　　约10% 　　约15% 　　约5% 　　约5% 　　约10% 　　约5% 　　约20% 　　约5% 　　约25% 　　这和实际比赛中的题型分布也是大体相当的。有兴趣的朋友可以去看看。 　　2、UVA： 　　UVA代表西班牙Valladolid大学(University de Valladolid)。该大学有一个那里设立了一个PROBLEM SET ARCHIVE with ONLINE JUDGE ，并且支持ONLINE JUDGE，形式和Ural大学的题库类似。不过和Ural不同的是，UVA题目多的多，而且比较杂，而且有些题目的测试数据比较刁钻。这使得刚到那里做题的朋友往往感觉到无所适从，要么难以找到合适的题目，要么Wrong Answer了很多次以后仍然不知道错在那里。 如果说做Ural题目主要是为了训练算法，那么UVA题目可以训练全方位的基本功和一些必要的编程素质。UVA和许多世界知名大学联合办有同步网上比赛，因此那里强人无数，不过你先要使自己具有听懂他们在说什么的素质：） 　　3、ZOJ： 　　ZOJ是浙江大学建立的ONLINE JUDGE，是中国大学建立的第一个同类站点，也是最好和人气最高的一个，笔者和许多班里的同学就是在这里练习。ZOJ虽然也定位为一个英文网站，但是这里的中国学生比较多，因此让人觉得很亲切。这里目前有500多道题目，难易分配适中，且涵盖了各大洲的题目类型并配有索引，除此之外，ZOJ的JUDGE系统是几个网站中表现得比较好的一个，很少出现Wrong Answer和Presentation error混淆的情况。这里每月也办有一次网上比赛，只要是注册的用户都可以参加。 　　说起中国的ONLINE JUDGE，去年才开始参加ACM竞赛的北京大学现在也建立了自己的提交系统；而我们学校也是去年开始参加比赛，现在也有可能推出自己的提交系统，如果能够做成，到时候大家就可以去上面做题了。同类网站的飞速发展标志着有越来越多的同学有兴趣进入信息学的领域探索，这是一件好事，同时也意味着更激烈的竞争。

92题 一般来说，建立INDEX有以下益处：提高查询效率；建立唯一索引以保证数据的唯一性；设计INDEX避免排序。 缺点，INDEX的维护有以下开销：叶节点的‘分裂’消耗；INSERT、DELETE和UPDATE操作在INDEX上的维护开销；有存储要求；其他日常维护的消耗：对恢复的影响，重组的影响。 需要建立索引的情况：为了建立分区数据库的PATITION INDEX必须建立； 为了保证数据约束性需要而建立的INDEX必须建立； 为了提高查询效率，则考虑建立（是否建立要考虑相关性能及维护开销）； 考虑在使用UNION,DISTINCT,GROUP BY,ORDER BY等字句的列上加索引。 91题 作用：加快查询速度。原则：(1) 如果某属性或属性组经常出现在查询条件中，考虑为该属性或属性组建立索引；(2) 如果某个属性常作为最大值和最小值等聚集函数的参数，考虑为该属性建立索引；(3) 如果某属性经常出现在连接操作的连接条件中，考虑为该属性或属性组建立索引。 90题 快照Snapshot是一个文件系统在特定时间里的镜像，对于在线实时数据备份非常有用。快照对于拥有不能停止的应用或具有常打开文件的文件系统的备份非常重要。对于只能提供一个非常短的备份时间而言，快照能保证系统的完整性。 89题 游标用于定位结果集的行，通过判断全局变量@@FETCH_STATUS可以判断是否到了最后，通常此变量不等于0表示出错或到了最后。 88题 事前触发器运行于触发事件发生之前，而事后触发器运行于触发事件发生之后。通常事前触发器可以获取事件之前和新的字段值。语句级触发器可以在语句执行前或后执行，而行级触发在触发器所影响的每一行触发一次。 87题 MySQL可以使用多个字段同时建立一个索引，叫做联合索引。在联合索引中，如果想要命中索引，需要按照建立索引时的字段顺序挨个使用，否则无法命中索引。具体原因为：MySQL使用索引时需要索引有序，假设现在建立了"name，age，school"的联合索引，那么索引的排序为: 先按照name排序，如果name相同，则按照age排序，如果age的值也相等，则按照school进行排序。因此在建立联合索引的时候应该注意索引列的顺序，一般情况下，将查询需求频繁或者字段选择性高的列放在前面。此外可以根据特例的查询或者表结构进行单独的调整。 86题 建立索引的时候一般要考虑到字段的使用频率，经常作为条件进行查询的字段比较适合。如果需要建立联合索引的话，还需要考虑联合索引中的顺序。此外也要考虑其他方面，比如防止过多的所有对表造成太大的压力。这些都和实际的表结构以及查询方式有关。 85题 存储过程是一组Transact-SQL语句，在一次编译后可以执行多次。因为不必重新编译Transact-SQL语句，所以执行存储过程可以提高性能。触发器是一种特殊类型的存储过程，不由用户直接调用。创建触发器时会对其进行定义，以便在对特定表或列作特定类型的数据修改时执行。 84题 存储过程是用户定义的一系列SQL语句的集合，涉及特定表或其它对象的任务，用户可以调用存储过程，而函数通常是数据库已定义的方法，它接收参数并返回某种类型的值并且不涉及特定用户表。 83题 减少表连接，减少复杂 SQL，拆分成简单SQL。减少排序：非必要不排序，利用索引排序，减少参与排序的记录数。尽量避免 select *。尽量用 join 代替子查询。尽量少使用 or，使用 in 或者 union(union all) 代替。尽量用 union all 代替 union。尽量早的将无用数据过滤：选择更优的索引，先分页再Join…。避免类型转换：索引失效。优先优化高并发的 SQL，而不是执行频率低某些“大”SQL。从全局出发优化，而不是片面调整。尽可能对每一条SQL进行 explain。 82题 如果条件中有or，即使其中有条件带索引也不会使用(要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引)。对于多列索引，不是使用的第一部分，则不会使用索引。like查询是以%开头。如果列类型是字符串，那一定要在条件中将数据使用引号引用起来，否则不使用索引。如果mysql估计使用全表扫描要比使用索引快，则不使用索引。例如，使用<>、not in 、not exist，对于这三种情况大多数情况下认为结果集很大，MySQL就有可能不使用索引。 81题 主键不能重复，不能为空，唯一键不能重复，可以为空。建立主键的目的是让外键来引用。一个表最多只有一个主键，但可以有很多唯一键。 80题 空值('')是不占用空间的，判断空字符用=''或者<>''来进行处理。NULL值是未知的，且占用空间，不走索引；判断 NULL 用 IS NULL 或者 is not null ，SQL 语句函数中可以使用 ifnull ()函数来进行处理。无法比较 NULL 和 0；它们是不等价的。无法使用比较运算符来测试 NULL 值，比如 =, <, 或者 <>。NULL 值可以使用 <=> 符号进行比较，该符号与等号作用相似，但对NULL有意义。进行 count ()统计某列的记录数的时候，如果采用的 NULL 值，会被系统自动忽略掉，但是空值是统计到其中。 79题 HEAP表是访问数据速度最快的MySQL表，他使用保存在内存中的散列索引。一旦服务器重启，所有heap表数据丢失。BLOB或TEXT字段是不允许的。只能使用比较运算符=，<，>，=>，= <。HEAP表不支持AUTO_INCREMENT。索引不可为NULL。 78题 如果想输入字符为十六进制数字，可以输入带有单引号的十六进制数字和前缀（X），或者只用（Ox）前缀输入十六进制数字。如果表达式上下文是字符串，则十六进制数字串将自动转换为字符串。 77题 Mysql服务器通过权限表来控制用户对数据库的访问，权限表存放在mysql数据库里，由mysql_install_db脚本初始化。这些权限表分别user，db，table_priv，columns_priv和host。 76题 在缺省模式下，MYSQL是autocommit模式的，所有的数据库更新操作都会即时提交，所以在缺省情况下，mysql是不支持事务的。但是如果你的MYSQL表类型是使用InnoDB Tables 或 BDB tables的话，你的MYSQL就可以使用事务处理,使用SET AUTOCOMMIT=0就可以使MYSQL允许在非autocommit模式，在非autocommit模式下，你必须使用COMMIT来提交你的更改，或者用ROLLBACK来回滚你的更改。 75题 它会停止递增，任何进一步的插入都将产生错误，因为密钥已被使用。 74题 创建索引的时候尽量使用唯一性大的列来创建索引，由于使用b+tree做为索引，以innodb为例，一个树节点的大小由“innodb_page_size”，为了减少树的高度，同时让一个节点能存放更多的值，索引列尽量在整数类型上创建，如果必须使用字符类型，也应该使用长度较少的字符类型。 73题 当MySQL单表记录数过大时，数据库的CRUD性能会明显下降，一些常见的优化措施如下： 限定数据的范围： 务必禁止不带任何限制数据范围条件的查询语句。比如：我们当用户在查询订单历史的时候，我们可以控制在一个月的范围内。读/写分离： 经典的数据库拆分方案，主库负责写，从库负责读。垂直分区： 根据数据库里面数据表的相关性进行拆分。简单来说垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表。水平分区： 保持数据表结构不变，通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中，达到了分布式的目的。水平拆分可以支撑非常大的数据量。 72题 乐观锁失败后会抛出ObjectOptimisticLockingFailureException，那么我们就针对这块考虑一下重试，自定义一个注解，用于做切面。针对注解进行切面，设置最大重试次数n，然后超过n次后就不再重试。 71题 一致性非锁定读讲的是一条记录被加了X锁其他事务仍然可以读而不被阻塞，是通过innodb的行多版本实现的，行多版本并不是实际存储多个版本记录而是通过undo实现（undo日志用来记录数据修改前的版本，回滚时会用到，用来保证事务的原子性）。一致性锁定读讲的是我可以通过SELECT语句显式地给一条记录加X锁从而保证特定应用场景下的数据一致性。 70题 数据库引擎：尤其是mysql数据库只有是InnoDB引擎的时候事物才能生效。 show engines 查看数据库默认引擎;SHOW TABLE STATUS from 数据库名字 where Name='表名' 如下;SHOW TABLE STATUS from rrz where Name='rrz_cust';修改表的引擎alter table table_name engine=innodb。 69题 如果是等值查询，那么哈希索引明显有绝对优势，因为只需要经过一次算法即可找到相应的键值；当然了，这个前提是，键值都是唯一的。如果键值不是唯一的，就需要先找到该键所在位置，然后再根据链表往后扫描，直到找到相应的数据；如果是范围查询检索，这时候哈希索引就毫无用武之地了，因为原先是有序的键值，经过哈希算法后，有可能变成不连续的了，就没办法再利用索引完成范围查询检索；同理，哈希索引也没办法利用索引完成排序，以及like ‘xxx%’ 这样的部分模糊查询（这种部分模糊查询，其实本质上也是范围查询）；哈希索引也不支持多列联合索引的最左匹配规则；B+树索引的关键字检索效率比较平均，不像B树那样波动幅度大，在有大量重复键值情况下，哈希索引的效率也是极低的，因为存在所谓的哈希碰撞问题。 68题 decimal精度比float高,数据处理比float简单，一般优先考虑，但float存储的数据范围大，所以范围大的数据就只能用它了，但要注意一些处理细节，因为不精确可能会与自己想的不一致，也常有关于float 出错的问题。 67题 datetime、timestamp精确度都是秒，datetime与时区无关，存储的范围广(1001-9999)，timestamp与时区有关，存储的范围小(1970-2038)。 66题 Char使用固定长度的空间进行存储，char(4)存储4个字符，根据编码方式的不同占用不同的字节，gbk编码方式，不论是中文还是英文，每个字符占用2个字节的空间，utf8编码方式，每个字符占用3个字节的空间。Varchar保存可变长度的字符串，使用额外的一个或两个字节存储字符串长度，varchar(10),除了需要存储10个字符，还需要1个字节存储长度信息(10),超过255的长度需要2个字节来存储。char和varchar后面如果有空格，char会自动去掉空格后存储，varchar虽然不会去掉空格，但在进行字符串比较时，会去掉空格进行比较。Varbinary保存变长的字符串，后面不会补\0。 65题 首先分析语句，看看是否load了额外的数据，可能是查询了多余的行并且抛弃掉了，可能是加载了许多结果中并不需要的列，对语句进行分析以及重写。分析语句的执行计划，然后获得其使用索引的情况，之后修改语句或者修改索引，使得语句可以尽可能的命中索引。如果对语句的优化已经无法进行，可以考虑表中的数据量是否太大，如果是的话可以进行横向或者纵向的分表。 64题 建立索引的时候一般要考虑到字段的使用频率，经常作为条件进行查询的字段比较适合。如果需要建立联合索引的话，还需要考虑联合索引中的顺序。此外也要考虑其他方面，比如防止过多的所有对表造成太大的压力。这些都和实际的表结构以及查询方式有关。 63题 存储过程是一些预编译的SQL语句。1、更加直白的理解：存储过程可以说是一个记录集，它是由一些T-SQL语句组成的代码块，这些T-SQL语句代码像一个方法一样实现一些功能（对单表或多表的增删改查），然后再给这个代码块取一个名字，在用到这个功能的时候调用他就行了。2、存储过程是一个预编译的代码块，执行效率比较高，一个存储过程替代大量T_SQL语句 ，可以降低网络通信量，提高通信速率，可以一定程度上确保数据安全。 62题 密码散列、盐、用户身份证号等固定长度的字符串应该使用char而不是varchar来存储,这样可以节省空间且提高检索效率。 61题 推荐使用自增ID，不要使用UUID。因为在InnoDB存储引擎中，主键索引是作为聚簇索引存在的，也就是说，主键索引的B+树叶子节点上存储了主键索引以及全部的数据(按照顺序)，如果主键索引是自增ID，那么只需要不断向后排列即可，如果是UUID，由于到来的ID与原来的大小不确定，会造成非常多的数据插入,数据移动,然后导致产生很多的内存碎片，进而造成插入性能的下降。总之,在数据量大一些的情况下,用自增主键性能会好一些。 60题 char是一个定长字段，假如申请了char(10)的空间，那么无论实际存储多少内容。该字段都占用10个字符，而varchar是变长的，也就是说申请的只是最大长度，占用的空间为实际字符长度+1，最后一个字符存储使用了多长的空间。在检索效率上来讲，char > varchar，因此在使用中，如果确定某个字段的值的长度，可以使用char，否则应该尽量使用varchar。例如存储用户MD5加密后的密码,则应该使用char。 59题 一. read uncommitted（读取未提交数据） 即便是事务没有commit，但是我们仍然能读到未提交的数据，这是所有隔离级别中最低的一种。 二. read committed（可以读取其他事务提交的数据）---大多数数据库默认的隔离级别 当前会话只能读取到其他事务提交的数据，未提交的数据读不到。 三. repeatable read（可重读）---MySQL默认的隔离级别 当前会话可以重复读，就是每次读取的结果集都相同，而不管其他事务有没有提交。 四. serializable（串行化） 其他会话对该表的写操作将被挂起。可以看到，这是隔离级别中最严格的，但是这样做势必对性能造成影响。所以在实际的选用上，我们要根据当前具体的情况选用合适的。 58题 B+树的高度一般为2-4层，所以查找记录时最多只需要2-4次IO，相对二叉平衡树已经大大降低了。范围查找时，能通过叶子节点的指针获取数据。例如查找大于等于3的数据，当在叶子节点中查到3时，通过3的尾指针便能获取所有数据，而不需要再像二叉树一样再获取到3的父节点。 57题 因为事务在修改页时，要先记 undo，在记 undo 之前要记 undo 的 redo， 然后修改数据页，再记数据页修改的 redo。 Redo（里面包括 undo 的修改） 一定要比数据页先持久化到磁盘。 当事务需要回滚时，因为有 undo，可以把数据页回滚到前镜像的状态，崩溃恢复时，如果 redo log 中事务没有对应的 commit 记录，那么需要用 undo把该事务的修改回滚到事务开始之前。 如果有 commit 记录，就用 redo 前滚到该事务完成时并提交掉。 56题 redo log是物理日志,记录的是"在某个数据页上做了什么修改"。 binlog是逻辑日志,记录的是这个语句的原始逻辑,比如"给ID=2这一行的c字段加1"。 redo log是InnoDB引擎特有的;binlog是MySQL的Server层实现的,所有引擎都可以使用。 redo log是循环写的,空间固定会用完:binlog 是可以追加写入的。"追加写"是指binlog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。 最开始 MySQL 里并没有 InnoDB 引擎，MySQL 自带的引擎是 MyISAM，但是 MyISAM 没有 crash-safe 的能力,binlog日志只能用于归档。而InnoDB 是另一个公司以插件形式引入 MySQL 的，既然只依靠 binlog 是没有 crash-safe 能力的，所以 InnoDB 使用另外一套日志系统，也就是 redo log 来实现 crash-safe 能力。 55题 重做日志（redo log)      作用：确保事务的持久性，防止在发生故障，脏页未写入磁盘。重启数据库会进行redo log执行重做，达到事务一致性。 回滚日志（undo log)  作用：保证数据的原子性，保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读(MVCC)，也即非锁定读。 二进 制日志（binlog)    作用：用于主从复制，实现主从同步；用于数据库的基于时间点的还原。 错误日志（errorlog) 作用：Mysql本身启动，停止，运行期间发生的错误信息。 慢查询日志（slow query log)  作用：记录执行时间过长的sql，时间阈值可以配置，只记录执行成功。 一般查询日志（general log)    作用：记录数据库的操作明细，默认关闭，开启后会降低数据库性能 。 中继日志（relay log) 作用：用于数据库主从同步，将主库发来的bin log保存在本地，然后从库进行回放。 54题 MySQL有三种锁的级别：页级、表级、行级。 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。 死锁: 是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。 死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。 那么对应的解决死锁问题的关键就是：让不同的session加锁有次序。死锁的解决办法：1.查出的线程杀死。2.设置锁的超时时间。3.指定获取锁的顺序。 53题 当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性(脏读，不可重复读，幻读等)，可能产生死锁。 乐观锁：乐观锁不是数据库自带的，需要我们自己去实现。 悲观锁：在进行每次操作时都要通过获取锁才能进行对相同数据的操作。 共享锁：加了共享锁的数据对象可以被其他事务读取，但不能修改。 排他锁：当数据对象被加上排它锁时，一个事务必须得到锁才能对该数据对象进行访问，一直到事务结束锁才被释放。 行锁：就是给某一条记录加上锁。 52题 Mysql是关系型数据库，MongoDB是非关系型数据库，数据存储结构的不同。 51题 关系型数据库优点：1.保持数据的一致性（事务处理）。 2.由于以标准化为前提，数据更新的开销很小。 3. 可以进行Join等复杂查询。 缺点：1、为了维护一致性所付出的巨大代价就是其读写性能比较差。 2、固定的表结构。 3、高并发读写需求。 4、海量数据的高效率读写。 非关系型数据库优点：1、无需经过sql层的解析，读写性能很高。 2、基于键值对，数据没有耦合性，容易扩展。 3、存储数据的格式：nosql的存储格式是key,value形式、文档形式、图片形式等等，文档形式、图片形式等等，而关系型数据库则只支持基础类型。 缺点：1、不提供sql支持，学习和使用成本较高。 2、无事务处理，附加功能bi和报表等支持也不好。 redis与mongoDB的区别： 性能：TPS方面redis要大于mongodb。 可操作性：mongodb支持丰富的数据表达，索引，redis较少的网络IO次数。 可用性:MongoDB优于Redis。 一致性:redis事务支持比较弱,mongoDB不支持事务。 数据分析:mongoDB内置了数据分析的功能(mapreduce)。 应用场景:redis数据量较小的更性能操作和运算上,MongoDB主要解决海量数据的访问效率问题。 50题 如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。 49题 分区可以让Redis管理更大的内存，Redis将可以使用所有机器的内存。如果没有分区，你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。 48题 除了缓存服务器自带的缓存失效策略之外（Redis默认的有6种策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种： 1.定时去清理过期的缓存； 2.当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。 两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，可以根据应用场景来权衡。 47题 Redis提供了两种方式来作消息队列: 一个是使用生产者消费模式模式:会让一个或者多个客户端监听消息队列，一旦消息到达，消费者马上消费，谁先抢到算谁的，如果队列里没有消息，则消费者继续监听 。另一个就是发布订阅者模式:也是一个或多个客户端订阅消息频道，只要发布者发布消息，所有订阅者都能收到消息，订阅者都是平等的。 46题 Redis的数据结构列表(list)可以实现延时队列，可以通过队列和栈来实现。blpop/brpop来替换lpop/rpop，blpop/brpop阻塞读在队列没有数据的时候，会立即进入休眠状态，一旦数据到来，则立刻醒过来。Redis的有序集合(zset)可以用于实现延时队列，消息作为value，时间作为score。Zrem 命令用于移除有序集中的一个或多个成员，不存在的成员将被忽略。当 key 存在但不是有序集类型时，返回一个错误。 45题 1.热点数据缓存：因为Redis 访问速度块、支持的数据类型比较丰富。 2.限时业务：expire 命令设置 key 的生存时间，到时间后自动删除 key。 3.计数器：incrby 命令可以实现原子性的递增。 4.排行榜：借助 SortedSet 进行热点数据的排序。 5.分布式锁：利用 Redis 的 setnx 命令进行。 6.队列机制：有 list push 和 list pop 这样的命令。 44题 一致哈希 是一种特殊的哈希算法。在使用一致哈希算法后，哈希表槽位数（大小）的改变平均只需要对 K/n 个关键字重新映射，其中K是关键字的数量， n是槽位数量。然而在传统的哈希表中，添加或删除一个槽位的几乎需要对所有关键字进行重新映射。 43题 RDB的优点：适合做冷备份；读写服务影响小，reids可以保持高性能；重启和恢复redis进程，更加快速。RDB的缺点：宕机会丢失最近5分钟的数据；文件特别大时可能会暂停数毫秒，或者甚至数秒。 AOF的优点：每个一秒执行fsync操作，最多丢失1秒钟的数据；以append-only模式写入，没有任何磁盘寻址的开销；文件过大时，不会影响客户端读写；适合做灾难性的误删除的紧急恢复。AOF的缺点：AOF日志文件比RDB数据快照文件更大，支持写QPS比RDB支持的写QPS低；比RDB脆弱，容易有bug。 42题 对于Redis而言，命令的原子性指的是：一个操作的不可以再分，操作要么执行，要么不执行。Redis的操作之所以是原子性的，是因为Redis是单线程的。而在程序中执行多个Redis命令并非是原子性的，这也和普通数据库的表现是一样的，可以用incr或者使用Redis的事务，或者使用Redis+Lua的方式实现。对Redis来说，执行get、set以及eval等API，都是一个一个的任务，这些任务都会由Redis的线程去负责执行，任务要么执行成功，要么执行失败，这就是Redis的命令是原子性的原因。 41题 (1)twemproxy,使用方式简单（相对redis只需修改连接端口），对旧项目扩展的首选。(2)codis,目前用的最多的集群方案，基本和twemproxy一致的效果，但它支持在节点数改变情况下，旧节点数据可恢复到新hash节点。(3)redis cluster3.0自带的集群，特点在于他的分布式算法不是一致性hash,而是hash槽的概念，以及自身支持节点设置从节点。(4)在业务代码层实现，起几个毫无关联的redis实例，在代码层，对key进行hash计算，然后去对应的redis实例操作数据。这种方式对hash层代码要求比较高，考虑部分包括，节点失效后的代替算法方案，数据震荡后的自动脚本恢复，实例的监控，等等。 40题 (1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件 (2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次 (3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内 (4) 尽量避免在压力很大的主库上增加从库 (5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3...这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。 39题 比如订单管理，热数据：3个月内的订单数据，查询实时性较高;温数据：3个月 ~ 12个月前的订单数据，查询频率不高;冷数据：1年前的订单数据，几乎不会查询，只有偶尔的查询需求。热数据使用mysql进行存储，需要分库分表;温数据可以存储在ES中，利用搜索引擎的特性基本上也可以做到比较快的查询;冷数据可以存放到Hive中。从存储形式来说，一般情况冷数据存储在磁带、光盘，热数据一般存放在SSD中，存取速度快，而温数据可以存放在7200转的硬盘。 38题 当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。 37题 分层架构设计，有一条准则：站点层、服务层要做到无数据无状态，这样才能任意的加节点水平扩展，数据和状态尽量存储到后端的数据存储服务，例如数据库服务或者缓存服务。显然进程内缓存违背了这一原则。 36题 更新数据的时候，根据数据的唯一标识，将操作路由之后，发送到一个 jvm 内部队列中。读取数据的时候，如果发现数据不在缓存中，那么将重新读取数据+更新缓存的操作，根据唯一标识路由之后，也发送同一个 jvm 内部队列中。一个队列对应一个工作线程，每个工作线程串行拿到对应的操作，然后一条一条的执行。 35题 redis分布式锁加锁过程：通过setnx向特定的key写入一个随机值，并同时设置失效时间，写值成功既加锁成功；redis分布式锁解锁过程：匹配随机值，删除redis上的特点key数据，要保证获取数据、判断一致以及删除数据三个操作是原子的，为保证原子性一般使用lua脚本实现；在此基础上进一步优化的话，考虑使用心跳检测对锁的有效期进行续期，同时基于redis的发布订阅优雅的实现阻塞式加锁。 34题 volatile-lru：当内存不足以容纳写入数据时，从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。 volatile-ttl：当内存不足以容纳写入数据时，从已设置过期时间的数据集中挑选将要过期的数据淘汰。 volatile-random：当内存不足以容纳写入数据时，从已设置过期时间的数据集中任意选择数据淘汰。 allkeys-lru：当内存不足以容纳写入数据时，从数据集中挑选最近最少使用的数据淘汰。 allkeys-random：当内存不足以容纳写入数据时，从数据集中任意选择数据淘汰。 noeviction：禁止驱逐数据，当内存使用达到阈值的时候，所有引起申请内存的命令会报错。 33题 定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。 惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。 定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。 32题 缓存击穿，一个存在的key，在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到DB，造成瞬时DB请求量大、压力骤增。如何避免：在访问key之前，采用SETNX（set if not exists）来设置另一个短期key来锁住当前key的访问，访问结束再删除该短期key。 31题 缓存雪崩，是指在某一个时间段，缓存集中过期失效。大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩。而缓存服务器某个节点宕机或断网，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。如何避免：1.redis高可用，搭建redis集群。2.限流降级，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。3.数据预热，在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间。 30题 缓存穿透，是指查询一个数据库一定不存在的数据。正常的使用缓存流程大致是，数据查询先进行缓存查询，如果key不存在或者key已经过期，再对数据库进行查询，并把查询到的对象，放进缓存。如果数据库查询对象为空，则不放进缓存。一些恶意的请求会故意查询不存在的 key，请求量很大，对数据库造成压力，甚至压垮数据库。 如何避免：1：对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该 key 对应的数据 insert 了之后清理缓存。2：对一定不存在的 key 进行过滤。可以把所有的可能存在的 key 放到一个大的 Bitmap 中，查询时通过该 bitmap 过滤。 29题 1.memcached 所有的值均是简单的字符串，redis 作为其替代者，支持更为丰富的数据类型。 2.redis 的速度比 memcached 快很多。 3.redis 可以持久化其数据。 4.Redis支持数据的备份，即master-slave模式的数据备份。 5.Redis采用VM机制。 6.value大小：redis最大可以达到1GB，而memcache只有1MB。 28题 Spring Boot 推荐使用 Java 配置而非 XML 配置，但是 Spring Boot 中也可以使用 XML 配置，通过spring提供的@ImportResource来加载xml配置。例如：@ImportResource({"classpath:some-context.xml","classpath:another-context.xml"}) 27题 Spring像一个大家族，有众多衍生产品例如Spring Boot，Spring Security等等，但他们的基础都是Spring的IOC和AOP，IOC提供了依赖注入的容器，而AOP解决了面向切面的编程，然后在此两者的基础上实现了其他衍生产品的高级功能。Spring MVC是基于Servlet的一个MVC框架，主要解决WEB开发的问题，因为 Spring的配置非常复杂，各种xml，properties处理起来比较繁琐。Spring Boot遵循约定优于配置，极大降低了Spring使用门槛，又有着Spring原本灵活强大的功能。总结：Spring MVC和Spring Boot都属于Spring，Spring MVC是基于Spring的一个MVC框架，而Spring Boot是基于Spring的一套快速开发整合包。 26题 YAML 是 "YAML Ain't a Markup Language"（YAML 不是一种标记语言）的递归缩写。YAML 的配置文件后缀为 .yml，是一种人类可读的数据序列化语言，可以简单表达清单、散列表，标量等数据形态。它通常用于配置文件，与属性文件相比，YAML文件就更加结构化，而且更少混淆。可以看出YAML具有分层配置数据。 25题 Spring Boot有3种热部署方式： 1.使用springloaded配置pom.xml文件，使用mvn spring-boot:run启动。 2.使用springloaded本地加载启动，配置jvm参数-javaagent:<jar包地址> -noverify。 3.使用devtools工具包，操作简单，但是每次需要重新部署。 用

Re我和iDBCloud登录数据库的故事 11到13年做DBA的时候，最早接触的是iDB，我的理解之所以叫iDB应该是表达我的数据库的含义吧，估计我还是上学的时候就已经有了，目前iDB已经迭代到3.0，明年初会发布4.0，从DBA视角上看iDB就是可以review业务SQL，自动执行线上DDL，业务数据提取的申请和审批，WEB上的数据查询，最近做产品经理后才有机会系统的审视iDB（一个包含研发支撑、安全管控的企业级数据库管理产品），支撑了淘宝、天猫、支付宝(现在叫蚂蚁金服)的研发流程，保障了每年的双十一，但iDB Cloud与iDB不是一个产品，iDB是企业版的数据库管理产品，iDB Cloud则定位于个人版数据管理，相比企业中的流程约束，iDB Cloud更期望给大家提供在约束下的易用性最大化的灵活数据管理服务！ ------------------------- Re我和iDBCloud登录数据库的故事 这个月实例信息-实时性能UI改版发布，新版看起来还是比较舒服的！这个我在5元RDS大促时买的，没有跑业务，所以指标都是0，哈哈 实时性能的原型取自阿里DBA团队的传奇(朱旭)之手：orzdba，貌似很久之前已经开源，谷歌下便知! 翻出之前做DBA使用orzdba观察测试机器压测的截图，orzdba是用perl写的，检查项还是蛮多的，比如io吞吐量、rt、主机的load、swap、innodb row、innodb状态，这些是iDB Cloud没有的功能，iDB Cloud通过用户登录账号访问数据库，只能拿到MySQL进程内存中的状态信息，没有权限拿到主机指标，不过innodb相关信息是可以拿到的，但是考虑一般只有DBA才会关注这些细节，所以没开放，不知道大家还会关注什么指标？有没有办法拿到主机的指标？ ------------------------- 回5楼ringtail的帖子 刷新页面，类似关闭并重新打开，啥都没了，这个应该是正常的行为，话说为什么要刷新呢，我记得首页性能指标每5分钟自动刷新，即使点击页面上提供的刷新是没啥事的，而实时性能是每4秒更新一行的，还有什么场景要刷洗整个页面是我没想到的吗？ ------------------------- 回7楼ringtail的帖子 目前据我所知，真心还做不到刷新不丢iDB Cloud已经打开的选项卡、sql语句和执行结果什么的，现在只能在刷新时加一个“导航确认”，减少手痒式误刷新，哈哈 ------------------------- Re我和iDBCloud登录数据库的故事 翻工单时，发现有人关心使用iDB Cloud是否会收取流量费，我也没搞清楚，于是问了几个同事，终于把场景基本覆盖了，最终结论： 只要你不把你的RDS实例切换成外网（公网）模式的同时再导出或查询数据就不会收取流量费！ 由于那几个工单已经关闭，我就在这里回复下大家，希望那几个朋友能看到 ------------------------- 回9楼yzsind的帖子 一定不会辜负领导的期望，努力工作，争取升职加薪，当上总经理，出任ceo，迎娶白富美，想想还有点小激动 ------------------------- 回10楼佩恩六道的帖子 可能文字不好理解整体的流量计费情况，中午用我那小学的美术细胞，完成了一副“巨作”！ ------------------------- Re我和iDBCloud登录数据库的故事 刚才看到一个工单（iDB Cloud点击登录无效），这个工单已经处理完毕，但我觉得可以把售后同学的方法和大家分享下！ 以后遇到点击登录无效、登录后菜单栏点击无效、页面展示不全，很可能是浏览器兼容设置的问题！ 浏览器兼容设置的问题： 1.检查浏览器是否安装了AdBlockPlus（火狐浏览器的一个扩展），用火狐浏览器的用户遇到类似问题要注意这一点 2.IE浏览器的话就调整下兼容性模式（http://jingyan.baidu.com/article/fcb5aff791bb47edaa4a7115.html ），并进入开发者模式再测试下IDB Cloud 如果上述2招还是解决不了，记得留言给我！ ------------------------- Re我和iDBCloud登录数据库的故事 今天看工单时发现有个朋友反馈，包含mediumblob类型字段的表在做导出后，导出文件中没有mediumblob类型字段！ 其实导出时默认是不会导出BLOB类型字段，但是在导出-高级选项中是可以选择导出BLOB，但是BLOB字段只能以16进制格式导出，试想一个WORD文档或者一首歌曲，16进制导出后，没啥意义！ BOLB字段支持WEB界面上传和下载，是原文件呀，哈哈！ ------------------------- Re我和iDBCloud登录数据库的故事 未来几天休假，去考驾照 ------------------------- Re我和iDBCloud登录数据库的故事 看工单和论坛中，有用户会抱怨产品不好用，然后就消失了，真的好可惜！ 作为产品经理是很想倾听这些抱怨背后的真实想法，期待可以直接对话，无论是功能缺失，还是操作不便，哪怕是使用上的一种感觉或产品散发的味道不对都可以，不求需求，只求对话！ ------------------------- Re我和iDBCloud登录数据库的故事 感谢你的关注和支持！ 产品说到底不是产品经理个人的，也不是哪个企业的，而是用户的产品，水能载舟亦能覆舟，产品经理和企业只不过在帮用户把需求实现而已，所以我们会一直坚持下去，坚持和用户一起把iDB Cloud做得更好 ------------------------- Re我和iDBCloud登录数据库的故事 最近几天公司感冒发烧的同学很多，我也是坚持了好几天才沦陷的，这是在我记忆中来杭州4年第一次发烧，看来20多年在东北积累的体质终于被消耗殆尽，不过意外收获是在高烧间隔清醒之际对最近自己的所作所为反倒有了一些悔悟，有些是工作上，有些是做人上 ------------------------- 回24楼zhouzhenxing的帖子 可以的，iDB Cloud对RDS公网和私网模式都是支持的！ 你可以在RDS控制台-账号管理中 新建你的数据库账号，然后还是在RDS控制台的右上角，点击“登录数据库”就可以进入iDB Cloud了，建议你先自己试着玩玩，有困惑的话我们一同讨论 ------------------------- 回24楼zhouzhenxing的帖子 iDB Cloud在官网上有2个手册，写的比较官方，可能对你用处不大，我其实不太喜欢写什么手册，如果一个产品做的体验不好，只能靠手册来弥补还是有点low，不过我已经在想如何不low了，还是那句话 有困惑的话我们一同讨论 http://help.aliyun.com/doc/view/13526530.html?spm=0.0.0.0.6W7Qx1 http://help.aliyun.com/view/11108238_13861850.html?spm=5176.7224961.1997285473.4.Irtizv ------------------------- Re我和iDBCloud登录数据库的故事 都说在产品上做加法容易，做减法难，我理解无论产品功能还是工作上，给予总会得到别人的喜欢，而要求或收回时会得到对方的负面情绪，因此趋利避害，尽量不做减法，但有时候很难避免，这就要想想为什么要做减法？ 多数都是之前错误选择，做了过多的加法，因为普通的加法很好做，人们往往会趋之如骛，但是真正、正确的加法是要在拒绝几十到上百种选择基础上的最终选择，将复杂解决方案以极简形式展现出来，而不是解决方案和功能的堆积，所以未经严格挑选的加法对产品是有害的，工作也一样，不要贸然接受新工作，保证核心精力投入到核心工作上，摊子铺得太大，一定会遇到心力瓶颈，而心力一旦枯竭，再强的脑力也无法施展，任何一项工作都是以大量心力付出为前提，脑力提升我找到了一些办法，心力提升却一筹莫展，所以只好专注，要不全心投入，要不置身事外，今后功能和工作都要适时做做减法了！ ------------------------- Re我和iDBCloud登录数据库的故事 今天有个同事转给我一个工单，说从深圳云管理系统界面的iDB Cloud上看到库是utf8，而后端开发人员说库是gbk的，我查看了工单中截图附件（RDS控制台-参数设置），虽然从工单中无法完全断定用户遇到的问题，我还是大胆猜测下： 我看到截图上的character_set_server参数，首先character_set_server是RDS唯一开放的关于字符集的参数，但其实这个参数与用户在iDB Cloud上看到数据是否乱码没有关系，character_set_server其实就是默认的内部操作字符集，只有当字段->表->库都没有设置CHARACTER SET，才会使用character_set_server作为对应字段-表-库的默认字符集！ 透露一个秘诀（传男也传女）： (1)让你的字段-表-库的字符集都是utf8; (2)在iDB Cloud-命令窗口执行set names utf8；#会将character_set_client、character_set_connection和character_set_results都设置成utf8 只要让(1)和(2)字符集保持一致（utf8、gbk、latin1等），乱码就搞定了！ 不清楚为什么截图会变成上面这样！把在iDB Cloud-命令窗口上执行的命令和结果也粘下 mysql>set names gbk; 执行成功,花费 7.59 ms. mysql>show  variables like '%char%'; +--------------------------+----------------------------------+ | Variable_name            | Value                            | +--------------------------+----------------------------------+ | character_set_client     | gbk                              | | character_set_connection | gbk                              | | character_set_database   | gbk                              | | character_set_filesystem | binary                           | | character_set_results    | gbk                              | | character_set_server     | gbk                              | | character_set_system     | utf8                             | | character_sets_dir       | /u01/mysql/share/mysql/charsets/ | +--------------------------+----------------------------------+ 共返回 8 行记录,花费 10.51 ms. mysql>set names utf8; 执行成功,花费 7.32 ms. mysql>show  variables like '%char%'; +--------------------------+----------------------------------+ | Variable_name            | Value                            | +--------------------------+----------------------------------+ | character_set_client     | utf8                             | | character_set_connection | utf8                             | | character_set_database   | gbk                              | | character_set_filesystem | binary                           | | character_set_results    | utf8                             | | character_set_server     | gbk                              | | character_set_system     | utf8                             | | character_sets_dir       | /u01/mysql/share/mysql/charsets/ | +--------------------------+----------------------------------+ 共返回 8 行记录,花费 10.32 ms. ------------------------- Re我和iDBCloud登录数据库的故事 你的专属BUG： 发现时间 资深用户 专属BUG 2015-02-03 23:06 啊啊啊啊8  实例信息-实时性能-参数说明-【delete】 表示InnoDB存储引擎表的写入（删除）记录行数 ------------------------- Re我和iDBCloud登录数据库的故事 用户“夫子然”反馈说iDB Cloud感觉没phpMyAdmin方便！ 非常感谢这个用户的反馈，我先谈下我的理解，每个人使用产品都有一些固定的用例(use case)，我无法承诺针对任何人的任何用例，都做到最短操作路径（方便），这个用户抛出的问题也是我一直在思考的，虽然无法100%，但是我们可以覆盖主流用例，只要绝大多数的常规操作室是方便的，少数非经常用的操作路径长点，应该能接受吧，我们已经在行动！ 今天iDB Cloud发布了2.0.2，一个主要变化就是在左侧对象列表上增加了“列”和“索引”，正是我们分析数据看到在众多数据库对象中表的操作是最频繁的，而在表的操作中“列“和”索引“是最频繁的，这个版本将对“列”和“索引”的操作前置，缩短了主流用例路径，与用户“夫子然”的建议不谋而合，这只是开始，只要我们深挖，与功能和体验死磕，终有一天会让大家说iDB Cloud比phpMyAdmin方便！ ------------------------- 回31楼sqlserverdba的帖子 非常感谢！ 有你们作为后盾，有用户支持，才有iDB Cloud的现在和未来！ ------------------------- 消失了几天，终于把科目三和科目四搞定了，昨天终于拿到驾照了之前在【17楼】总结了科目二的一些体会，今天也分享下科目三的一点点感受！ 考试前几天，教练说是智能考（据说智能考比较简单，通过率很高），结果就留出考前2天练车时间，结果阴差阳错的换成了人工考（貌似是我们车是4个大老爷们，听教练说他一年最多抽到2次人工考就算多的啦，对此我只能呵呵），现在的问题就来了，4个人2天练车时间，一个人半天，那就从早到晚的练呗，我先简单描述下整个过程！ 1.心态(1)从开始练车到考试通过，心情没有特别大的起伏，不过考前失眠还是有的，哈哈(2)另外三个人，有的信心满满，有的吊儿郎当，有的不言不语，我应该也属于不言不语那种 2.练习(1)4个人轮流练，虽然一天下来很累，但还能挺住，开的时好时坏，不过总体上在变好(2)开车的时候几乎意识不到什么的，关键是在后座自己去琢磨，回忆自己错在哪里，为什么会错 3.考试(1)考试单上说7：00考试，结果在寒风中等了1个小时，终于盼来了考官，一共5辆车考试，我们是第二辆车(2)第一辆车是2男2女，2女都挂，当时我们第二辆车是被要求跟在第一辆车后面的，所以看的一清二楚，比如连续3次手刹未放下导致起步失败、4档走转弯到对向车道等(3)接下来到我们了，4男0女，结果挂了2男（信心满满和吊儿郎当） 上面只是简单介绍了科目三过程，下面才是干货！ 每年都有成千上万的人拿到驾照，我不认为自己牛，只是把我个人的应对方法和背后的原因拿出来分享下！练车其实就是教练的心智模型-翻译-语言-反译-我们的心智模型，让我们知道在什么情况做什么动作，预测路况，只要我们关于开车拥有了自己的心智模，开车就变成了一种本能，就像一旦学会了骑自行车，很难失去这种技能，在练车之前，我们是有自己关于开车的心智模型的，正所谓没吃过猪肉也见过猪跑，但是我们想想自己关于开车的心智模型是正确的吗？显然不是，不信你就试试去开车吧，抛开被交警抓之外，我想应该也能开起来，至于开的好不好，会不会一直开得好，我说不准，但是绝大多数人一定是开不好的，所以我们报驾校，除了硬性法律规定，驾校教练的确交会了很多东西，虽然很多是应试的技巧，这里就顺便说下这些技巧，技巧具体内容每家教练都会教的，而我想说的技巧其实就是“语言”，通过教练的“心智模型”-翻译出来的“语言”，接下来我们要做什么，“反译”将教练开车技巧的“语言”理解，首先你要虚心去接受，然后再去观察或运用，根据反馈把坏的放弃，把好的保留以便修正自己关于开车的“心智模型”，而“心智模型”最快速的形成方式就是亲身体验，所以一定要实战、要开车，还要经常开车，不断改进关于开车的“心智模型”，拿3个案例具体说下吧！【吊儿郎当】这两天都是下午才过来练车，开车时教练说一句话，他有十句等着，其中五句是解释自己为什么要这么做，另外五句是在问如果这种情况应该怎么做，如果那种情况怎么做，总是在关注自己想象中的场景，而不关注自己正在体验的场景，所以学来学去还是最初始的关于开车的“心智模型”，失败在“反译”这一步，认为只要听过就会了，结果被考官判直接挂掉并不予补考机会 【信心满满】与我们一直练车，对教练的话言听计从，而且也理解了，如果是上学时的考试或科目三智能考试一定没问题，但是面对人工考，评判是由交警而不是电脑，结果转向时没有观察后视镜，被考官迫停在路中间后开始补考，然后还是转向时没有观察后视镜，在路中间起步，之前学的技巧中没有应对的方法，结果还是挂了，教练也很惋惜，如果说他的失败，败于没有改进自己关于开车的“心智模型”，其实“反译”他做的很好，但是在运用、观察和反馈分析上做的不好，“心智模型”不是统一的标准，一定是个性化的，一定是自己认为是好的反馈、行为积累起来的，也只有“心智模型”才能在任何情况下帮助你做出判断，判断效果就取决于“心智模型”是否成熟，成熟的“心智模型”可以让在紧张、突发等情况下依然做出正确的判断，因为那是一种本能 【我】总说别人不好之处，也谈谈我自己，自然这些都是我事后分析总结的，练车过程中可没有感受到，我做的事情也很简单，就是“反译”和改进我的“心智模型”，“反译”，教练说什么，我就听什么，开车时来不及想，就在后座时在脑中模拟上演之前的场景并不断上演我不断修正的剧本，比如我的离合器总是抬的很快，经常熄火，特别是在路况复杂、指令突然时根本来不及思考如何应对，只能靠本能的时候，往往还是会快速抬离合器，因为我的“心智模型”中就是这么认为的，你可以说是离合器太低、座位太靠后，这些都是理由，如果是理由，那就去解决吧！我是这样做的，强制自己将抬离合器的动作拆成3步，即使不开车时也经常练习，慢慢的就变成了“心智模型”的一部分，自然在任何场景下都不会再出现离合器抬快熄火的情况了，这只是一个细节，其他细节也是类似，慢慢我的“心智模型”就建立起来了，开车技巧是很有用的，关键是你要理解这些技巧是要解决什么问题，你要解决相同问题时的做法是否相同，如果有不同之处是否正确，要去不断验证，如果是正确的，就改进到你的“心智模型”吧！ PD不光光是要把产品做好，我认为一个好PD应该能让整个世界变得更好！ ------------------------- Re我和iDBCloud登录数据库的故事 近期iDB Cloud将更名：DMS DMS (data management service) 数据管理服务 iDB Cloud从RDS起步，目前已经覆盖包括RDS、ADS、TAE，未来2个月还会覆盖万网和DRDS，同时ECS也开始兼容，“DMS”请各位新老用户，继续支持！ ------------------------- Re我和iDBCloud登录数据库的故事 1.使用HTTPS iDB Cloud这个4月份中旬版本就会支持HTTPS，敬请期待！ 2.设置账号是否允许登录iDB 3.31 会发布一个版本，这版本其中一个功能就是授权登录，允许实例owner设置该实例是否允许别人访问，允许谁可以访问 有如此心犀相通的用户，夫复何求！！！ 还有什么建议？ ------------------------- 回38楼pillowsky的帖子 好的，我先逐条对照分析下 ------------------------- Re我和iDBCloud登录数据库的故事 RDS数据库？RDS控制台-账号管理，检查下账号对不对，不行就重置密码 ------------------------- Re我和iDBCloud登录数据库的故事 3.31 DMS(原iDB Cloud) 在RDS上新版本发布！ 【实例授权】 DMS for MySQL 2.1发布！ 【会话统计】 DMS for SQL Server 2.0发布！ 【E-R图】 【对象列表】 ------------------------- Re我和iDBCloud登录数据库的故事 你是想听客服回复？算了，我还是从DMS PD 看RDS的视角来分享下吧！ RDS是一个数据库，在数据库之外包装了一些东西，帮用户做了备份恢复、HA、监控等，回到你提到的账号，root账号在MySQL里是权限最大的，也是风险最大的，为了保证RDS这些备份恢复、HA能7*24小时为你服务，所以就不能让你的账号去影响到这些组件，不然你一个误操作把实例关闭了怎么办，但是我承认目前RDS在控制台上提供的账号的确限制比较死，所以在RDS上你是无法获取root账号的，话说你要root权限做什么，你说的数据库创建在RDS控制台上提供功能了 ------------------------- 回46楼苗教授的帖子 客气了，也不知道能不能帮上你！ 如果从外看RDS的使用的话，可以在RDS控制台上去管理RDS实例（用用就熟悉了），或者直接调用OPEN API来完成实例管理操作，然后针对RDS实例中数据管理，就可以登录DMS，有几个常用链接发你看看，有问题可以在这里继续探讨！ DMS： http://idb.rds.aliyun.com/ DMS 功能介绍： http://docs.aliyun.com/#/rds/getting-started/database-manage&login-database OPEN API: http://docs.aliyun.com/?spm=5176.383715.9.5.1LioEO#/rds/open-api/abstract RDS控制台： https://rds.console.aliyun.com/console/index#/

从业余程序员到职业程序员 程序员刚入行时，我觉得最重要的是把自己培养成职业的程序员。 我的程序员起步比同龄人都晚了很多，更不用说现在的年轻人了。我大学读的是生物专业，在上大学前基本算是完全没接触过计算机。军训的时候因为很无聊，我和室友每天跑去学校的机房玩，我现在还印象很深刻，我第一次走进机房的时候，别人问，你是要玩windows，还是dos，我那是完全的一抹黑。后来就只记得在机房一堆人都是在练习盲打，军训完，盲打倒是练的差不多了，对计算机就这么产生了浓厚的兴趣，大一的时候都是玩组装机，捣鼓了一些，对计算机的硬件有了那么一些了解。 到大二后，买了一些书开始学习当时最火的网页三剑客，学会了手写HTML、PS的基本玩法之类的，课余、暑假也能开始给人做做网站什么的(那个时候做网站真的好赚钱)，可能那样过了个一年左右，做静态的网页就不好赚钱了，也不好找实习工作，于是就开始学asp，写些简单的CRUD，做做留言板、论坛这些动态程序，应该算是在这个阶段接触编程了。 毕业后加入了深圳的一家做政府行业软件的公司，一个非常靠谱和给我空间的Leader，使得自己在那几年有了不错的成长，终于成了一个职业的程序员。 通常来说，业余或半职业的程序员，多数是1个人，或者很小的一个团队一起开发，使得在开发流程、协作工具（例如jira、cvs/svn/git等）、测试上通常会有很大的欠缺，而职业的程序员在这方面则会专业很多。另外，通常职业的程序员做的系统都要运行较长的时间，所以在可维护性上会特别注意，这点我是在加入阿里后理解更深的。一个运行10年的系统，和一个写来玩玩的系统显然是有非常大差别的。 这块自己感觉也很难讲清楚，只能说模模糊糊有个这样的概念。通常在有兴趣的基础上，从业余程序员跨越到成为职业程序员我觉得不会太难。 编程能力的成长 作为程序员，最重要的能力始终是编程能力，就我自己的感受而言，我觉得编程能力的成长主要有这么几个部分： 1、编程能力初级：会用 编程，首先都是从学习编程语言的基本知识学起的，不论是什么编程语言，有很多共同的基本知识，例如怎么写第一个Hello World、if/while/for、变量等，因此我比较建议在刚刚开始学一门编程语言的时候，看看编程语言自己的一些文档就好，不要上来就去看一些高阶的书。我当年学Java的时候上来就看Think in Java、Effective Java之类的，真心好难懂。 除了看文档以外，编程是个超级实践的活，所以一定要多写代码，只有这样才能真正熟练起来。这也是为什么我还是觉得在面试的时候让面试者手写代码是很重要的，这个过程是非常容易判断写代码的熟悉程度的。很多人会说由于写代码都是高度依赖IDE的，导致手写很难，但我绝对相信写代码写了很多的人，手写一段不太复杂的、可运行的代码是不难的。即使像我这种三年多没写过代码的人，让我现在手写一段不太复杂的可运行的Java程序，还是没问题的，前面N年的写代码生涯使得很多东西已经深入骨髓了。 我觉得编程能力初级这个阶段对于大部分程序员来说都不会是问题，勤学苦练，是这个阶段的核心。 2、编程能力中级：会查和避免问题 除了初级要掌握的会熟练的使用编程语言去解决问题外，中级我觉得首先是提升查问题的能力。 在写代码的过程中，出问题是非常正常的，怎么去有效且高效的排查问题，是程序员群体中通常能感受到的大家在编程能力上最大的差距。 解决问题能力强的基本很容易在程序员群体里得到很高的认可。在查问题的能力上，首先要掌握的是一些基本的调试技巧，好用的调试工具，在Java里有JDK自带的jstat、jmap、jinfo，不在JDK里的有mat、gperf、btrace等。工欲善其事必先利其器，在查问题上是非常典型的，有些时候大家在查问题时的能力差距，有可能仅仅是因为别人比你多知道一个工具而已。 除了调试技巧和工具外，查问题的更高境界就是懂原理。一个懂原理的程序员在查问题的水平上和其他程序员是有明显差距的。我想很多的同学应该能感受到，有些时候查出问题的原因仅仅是因为有效的工具，知其然不知其所以然。 我给很多阿里的同学培训过Java排查问题的方法，在这个培训里，我经常也会讲到查问题的能力的培养最主要的也是熟练，多尝试给自己写一些会出问题的程序，多积极的看别人是怎么查问题的，多积极的去参与排查问题，很多最后查问题能力强的人多数仅仅是因为“无他，但手熟尔”。 我自己排查问题能力的提升主要是在2009年和2010年。那两年作为淘宝消防队（处理各种问题和故障的虚拟团队）的成员，处理了很多的故障和问题。当时消防队还有阿里最公认的技术大神——多隆，我向他学习到了很多排查问题的技巧。和他比，我排查问题的能力就是初级的那种。 印象最深刻的是一次我们一起查一个应用cpu us高的问题，我们两定位到是一段代码在某种输入参数的时候会造成cpu us高的原因后，我能想到的继续查的方法是去生产环境抓输入参数，然后再用参数来本地debug看是什么原因。但多隆在看了一会那段代码后，给了我一个输入参数，我拿这个参数一运行，果然cpu us很高！这种case不是一次两次。所以我经常和别人说，我是需要有问题场景才能排查出问题的，但多隆是完全有可能直接看代码就能看出问题的，这是本质的差距。 除了查问题外，更厉害的程序员是在写代码的过程就会很好的去避免问题。大家最容易理解的就是在写代码时处理各种异常情况，这里通常也是造成程序员们之间很大的差距的地方。 写一段正向逻辑的代码，大部分情况下即使有差距，也不会太大，但在怎么很好的处理这个过程中有可能出现的异常上，这个时候的功力差距会非常明显。很多时候一段代码里处理异常逻辑的部分都会超过正常逻辑的代码量。 我经常说，一个优秀程序员和普通程序员的差距，很多时候压根就不需要看什么满天飞的架构图，而只用show一小段的代码就可以。 举一个小case大家感受下。当年有一个严重故障，最后查出的原因是输入的参数里有一个是数组，把这个数组里的值作为参数去查数据库，结果前面输入了一个很大的数组，导致从数据库查了大量的数据，内存溢出了，很多程序员现在看都会明白对入参、出参的保护check，但类似这样的case我真的碰到了很多。 在中级这个阶段，我会推荐大家尽可能的多刻意的去培养下自己这两个方面的能力，成为一个能写出高质量代码、有效排查问题的优秀程序员。 3、编程能力高级：懂高级API和原理 就我自己的经历而言，我是在写了多年的Java代码后，才开始真正更细致的学习和掌握Java的一些更高级的API，我相信多数Java程序员也是如此。 我算是从2003年开始用Java写商业系统的代码，但直到在2007年加入淘宝后，才开始非常认真地学习Java的IO通信、并发这些部分的API。尽管以前也学过也写过一些这样的代码，但完全就是皮毛。当然，这些通常来说有很大部分的原因会是工作的相关性，多数的写业务系统的程序员可能基本就不需要用到这些，所以导致会很难懂这些相对高级一些的API，但这些API对真正的理解一门编程语言，我觉得至关重要。 在之前的程序员成长路线的文章里我也讲到了这个部分，在没有场景的情况下，只能靠自己去创造场景来学习好。我觉得只要有足够的兴趣，这个问题还是不大的，毕竟现在有各种开源，这些是可以非常好的帮助自己创造机会学习的，例如学Java NIO，可以自己基于NIO包一个框架，然后对比Netty，看看哪些写的是不如Netty的，这样会非常有助于真正的理解。 在学习高级API的过程中，以及排查问题的过程中，我自己越来越明白懂编程语言的运行原理是非常重要的，因此我到了后面的阶段开始学习Java的编译机制、内存管理、线程机制等。对于我这种非科班出身的而言，学这些会因为缺乏基础更难很多，但这些更原理性的东西学会了后，对自己的编程能力会有质的提升，包括以后学习其他编程语言的能力，学这些原理最好的方法我觉得是先看看一些讲相关知识的书，然后去翻看源码，这样才能真正的更好的掌握，最后是在以后写代码的过程中、查问题的过程中多结合掌握的原理，才能做到即使在N年后也不会忘。 在编程能力的成长上，我觉得没什么捷径。我非常赞同1万小时理论，在中级、高级阶段，如果有人指点或和优秀的程序员们共事，会好非常多。不过我觉得这个和读书也有点像，到了一定阶段后（例如高中），天分会成为最重要的分水岭，不过就和大部分行业一样，大部分的情况下都还没到拼天分的时候，只需要拼勤奋就好。 系统设计能力的成长 除了少数程序员会进入专深的领域，例如Linux Kernel、JVM，其他多数的程序员除了编程能力的成长外，也会越来越需要在系统设计能力上成长。 通常一个编程能力不错的程序员，在一定阶段后就会开始承担一个模块的工作，进而承担一个子系统、系统、跨多领域的更大系统等。 我自己在工作的第三年开始承担一个流程引擎的设计和实现工作，一个不算小的系统，并且也是当时那个项目里的核心部分。那个阶段我学会了一些系统设计的基本知识，例如需要想清楚整个系统的目标、模块的划分和职责、关键的对象设计等，而不是上来就开始写代码。但那个时候由于我是一个人写整个系统，所以其实对设计的感觉并还没有那么强力的感觉。 在那之后的几年也负责过一些系统，但总体感觉好像在系统设计上的成长没那么多，直到在阿里的经历，在系统设计上才有了越来越多的体会。（点击文末阅读原文，查看：我在系统设计上犯过的14个错，可以看到我走的一堆的弯路）。 在阿里有一次做分享，讲到我在系统设计能力方面的成长，主要是因为三段经历，负责专业领域系统的设计 -> 负责跨专业领域的专业系统的设计 -> 负责阿里电商系统架构级改造的设计。 第一段经历，是我负责HSF。HSF是一个从0开始打造的系统，它主要是作为支撑服务化的框架，是个非常专业领域的系统，放在整个淘宝电商的大系统来看，其实它就是一个很小的子系统，这段经历里让我最深刻的有三点： 1).要设计好这种非常专业领域的系统，专业的知识深度是非常重要的。我在最早设计HSF的几个框的时候，是没有设计好服务消费者/提供者要怎么和现有框架结合的，在设计负载均衡这个部分也反复了几次，这个主要是因为自己当时对这个领域掌握不深的原因造成的; 2). 太技术化。在HSF的阶段，出于情怀，在有一个版本里投入了非常大的精力去引进OSGi以及去做动态化，这个后来事实证明是个非常非常错误的决定，从这个点我才真正明白在设计系统时一定要想清楚目标，而目标很重要的是和公司发展阶段结合； 3). 可持续性。作为一个要在生产环境持续运行很多年的系统而言，怎么样让其在未来更可持续的发展，这个对设计阶段来说至关重要。这里最low的例子是最早设计HSF协议的时候，协议头里竟然没有版本号，导致后来升级都特别复杂；最典型的例子是HSF在早期缺乏了缺乏了服务Tracing这方面的设计，导致后面发现了这个地方非常重要后，全部落地花了长达几年的时间；又例如HSF早期缺乏Filter Chain的设计，导致很多扩展、定制化做起来非常不方便。 第二段经历，是做T4。T4是基于LXC的阿里的容器，它和HSF的不同是，它其实是一个跨多领域的系统，包括了单机上的容器引擎，容器管理系统，容器管理系统对外提供API，其他系统或用户通过这个来管理容器。这个系统发展过程也是各种犯错，犯错的主要原因也是因为领域掌握不深。在做T4的日子里，学会到的最重要的是怎么去设计这种跨多个专业领域的系统，怎么更好的划分模块的职责，设计交互逻辑，这段经历对我自己更为重要的意义是我有了做更大一些系统的架构的信心。 第三段经历，是做阿里电商的异地多活。这对我来说是真正的去做一个巨大系统的架构师，尽管我以前做HSF的时候参与了淘宝电商2.0-3.0的重大技术改造，但参与和自己主导是有很大区别的，这个架构改造涉及到了阿里电商众多不同专业领域的技术团队。在这个阶段，我学会的最主要的： 1). 子系统职责划分。在这种超大的技术方案中，很容易出现某些部分的职责重叠和冲突，这个时候怎么去划分子系统，就非常重要了。作为大架构师，这个时候要从团队的职责、团队的可持续性上去选择团队； 2). 大架构师最主要的职责是控制系统风险。对于这种超大系统，一定是多个专业领域的架构师和大架构师共同设计，怎么确保在执行的过程中对于系统而言最重要的风险能够被控制住，这是我真正的理解什么叫系统设计文档里设计原则的部分。 设计原则我自己觉得就是用来确保各个子系统在设计时都会遵循和考虑的，一定不能是虚的东西，例如在异地多活架构里，最重要的是如何控制数据风险，这个需要在原则里写上，最基本的原则是可接受系统不可用，但也要保障数据一致，而我看过更多的系统设计里设计原则只是写写的，或者千篇一律的，设计原则切实的体现了架构师对目标的理解（例如当时异地多活这个其实开始只是个概念，但做到什么程度才叫做到异地多活，这是需要解读的，也要确保在技术层面的设计上是达到了目标的），技术方案层面上的选择原则，并确保在细节的设计方案里有对于设计原则的承接以及执行； 3). 考虑问题的全面性。像异地多活这种大架构改造，涉及业务层面、各种基础技术层面、基础设施层面，对于执行节奏的决定要综合考虑人力投入、机器成本、基础设施布局诉求、稳定性控制等，这会比只是做一个小的系统的设计复杂非常多。 系统设计能力的成长，我自己觉得最重要的一是先在一两个技术领域做到专业，然后尽量扩大自己的知识广度。例如除了自己的代码部分外，还应该知道具体是怎么部署的，部署到哪去了，部署的环境具体是怎么样的，和整个系统的关系是什么样的。 像我自己，是在加入基础设施团队后才更加明白有些时候软件上做的一个决策，会导致基础设施上巨大的硬件、网络或机房的投入，但其实有可能只需要在软件上做些调整就可以避免，做做研发、做做运维可能是比较好的把知识广度扩大的方法。 第二点是练习自己做tradeoff的能力，这个比较难，做tradeoff这事需要综合各种因素做选择，但这也是所有的架构师最关键的，可以回头反思下自己在做各种系统设计时做出的tradeoff是什么。这个最好是亲身经历，听一些有经验的架构师分享他们选择背后的逻辑也会很有帮助，尤其是如果恰好你也在同样的挑战阶段，光听最终的架构结果其实大多数时候帮助有限。 技术Leader我觉得最好是能在架构师的基础上，后续注重成长的方面还是有挺大差别，就不在这篇里写了，后面再专门来写一篇。 程序员金字塔 我认为程序员的价值关键体现在作品上，被打上作品标签是一种很大的荣幸，作品影响程度的大小我觉得决定了金字塔的层次，所以我会这么去理解程序员的金字塔。 当然，要打造一款作品，仅有上面的两点能力是不够的，作品里很重要的一点是对业务、技术趋势的判断。 希望作为程序员的大伙，都能有机会打造一款世界级的作品，去为技术圈的发展做出贡献。 由于目前IT技术更新速度还是很快的，程序员这个行当是特别需要学习能力的。我一直认为，只有对程序员这个职业真正的充满兴趣，保持自驱，才有可能在这个职业上做好，否则的话是很容易淘汰的。 作者简介： 毕玄，2007年加入阿里，十多年来主要从事在软件基础设施领域，先后负责阿里的服务框架、Hbase、Sigma、异地多活等重大的基础技术产品和整体架构改造。