算法复杂性分析出现问题怎么解决

曾经因为看不懂数据结构和算法，而一度怀疑是自己太笨，实际上，很多人在第一次接触这门课时，都会有这种感觉，觉得数据结构和算法很抽象，晦涩难懂，宛如天书。正是这个原因，让很多初学者对这门课望而却步，希望以下分享能为初学者排忧解难。 我个人觉得，其实真正的原因是你没有找到好的学习方法，没有抓住学习的重点。实际上，数据结构和算法的东西并不多，常用的、基础的知识点更是屈指可数。只要掌握了正确的学习方法，学起来并没有看上去那么难，更不需要什么高智商、厚底子。 还记得大学里每次考前老师都要划重点吗？今天，我就给你划划我们这门课的重点，再告诉你一些我总结的学习小窍门。相信有了这些之后，你学起来就会有的放矢、事半功倍了。 什么是数据结构？什么是算法？ 大部分数据结构和算法教材，在开篇都会给这两个概念下一个明确的定义。但是，这些定义都很抽象，对理解这两个概念并没有实质性的帮助，反倒会让你陷入死抠定义的误区。毕竟，我们现在学习，并不是为了考试，所以，概念背得再牢，不会用也就没什么用。 虽然我们说没必要深挖严格的定义，但是这并不等于不需要理解概念。下面我就从广义和狭义两个层面，来帮你理解数据结构与算法这两个概念。 从广义上讲，数据结构就是指一组数据的存储结构。算法就是操作数据的一组方法。 图书馆储藏书籍你肯定见过吧？为了方便查找，图书管理员一般会将书籍分门别类进行“存储”。按照一定规律编号，就是书籍这种“数据”的存储结构。 那我们如何来查找一本书呢？有很多种办法，你当然可以一本一本地找，也可以先根据书籍类别的编号，是人文，还是科学、计算机，来定位书架，然后再依次查找。笼统地说，这些查找方法都是算法。 从狭义上讲，是指某些著名的数据结构和算法，比如队列、栈、堆、二分查找、动态规划等。这些都是前人智慧的结晶，我们可以直接拿来用。我们要讲的这些经典数据结构和算法，都是前人从很多实际操作场景中抽象出来的，经过非常多的求证和检验，可以高效地帮助我们解决很多实际的开发问题。 那数据结构和算法有什么关系呢？为什么大部分书都把这两个东西放到一块儿来讲呢？ 这是因为，数据结构和算法是相辅相成的。数据结构是为算法服务的，算法要作用在特定的数据结构之上。因此，我们无法孤立数据结构来讲算法，也无法孤立算法来讲数据结构。 比如，因为数组具有随机访问的特点，常用的二分查找算法需要用数组来存储数据。但如果我们选择链表这种数据结构，二分查找算法就无法工作了，因为链表并不支持随机访问。 数据结构是静态的，它只是组织数据的一种方式。如果不在它的基础上操作、构建算法，孤立存在的数据结构就是没用的。 现在你对数据结构与算法是不是有了比较清晰的理解了呢？有了这些储备，下面我们来看看，究竟该怎么学数据结构与算法。 看到数据结构和算法里的“算法”两个字，很多人就会联想到“数学”，觉得算法会涉及到很多深奥的数学知识。那我数学基础不是很好，学起来会不会很吃力啊？ 数据结构和算法课程确实会涉及一些数学方面的推理、证明，尤其是在分析某个算法的时间、空间复杂度的时候，但是这个你完全不需要担心。 学习的重点在什么地方？ 提到数据结构和算法，很多人就很头疼，因为这里面的内容实在是太多了。这里，我就帮你梳理一下，应该先学什么，后学什么。你可以对照看看，你属于哪个阶段，然后有针对地进行学习。 想要学习数据结构与算法，首先要掌握一个数据结构与算法中最重要的概念——复杂度分析。 这个概念究竟有多重要呢？可以这么说，它几乎占了数据结构和算法这门课的半壁江山，是数据结构和算法学习的精髓。 数据结构和算法解决的是如何更省、更快地存储和处理数据的问题，因此，我们就需要一个考量效率和资源消耗的方法，这就是复杂度分析方法。所以，如果你只掌握了数据结构和算法的特点、用法，但是没有学会复杂度分析，那就相当于只知道操作口诀，而没掌握心法。只有把心法了然于胸，才能做到无招胜有招！ 所以，复杂度分析这个内容，你也一定要花大力气来啃，必须要拿下，并且要搞得非常熟练。否则，后面的数据结构和算法也很难学好。 搞定复杂度分析，下面就要进入数据结构与算法的正文内容了。 为了让你对数据结构和算法能有个全面的认识，我画了一张图，里面几乎涵盖了所有数据结构和算法书籍中都会讲到的知识点。 但是，作为初学者，或者一个非算法工程师来说，你并不需要掌握图里面的所有知识点。很多高级的数据结构与算法，比如二分图、最大流等，这些在我们平常的开发中很少会用到。所以，你暂时可以不用看。我还是那句话，咱们学习要学会找重点。如果不分重点地学习，眉毛胡子一把抓，学起来肯定会比较吃力。 所以，结合我自己的学习心得，还有这些年的面试、开发经验，我总结了20个最常用的、最基础数据结构与算法，不管是应付面试还是工作需要，只要集中精力逐一攻克这20个知识点就足够了。 这里面有10个数据结构：数组、链表、栈、队列、散列表、二叉树、堆、跳表、图、Trie树；10个算法：递归、排序、二分查找、搜索、哈希算法、贪心算法、分治算法、回溯算法、动态规划、字符串匹配算法。 掌握了这些基础的数据结构和算法，再学更加复杂的数据结构和算法，就会非常容易、非常快。 与此同时，为了帮助大家学习算法，准备了一份学习资料，获取方式：关注我的公众号“程序媛不是程序猿”，回复“算法”即可弹出领取地址。对于新手来说很适用。 在学习数据结构和算法的过程中，你也要注意，不要只是死记硬背，不要为了学习而学习，而是要学习它的“来历”“自身的特点”“适合解决的问题”以及“实际的应用场景”。对于每一种数据结构或算法，我都会从这几个方面进行详细讲解。只要你掌握了《数据结构与算法之美》每节课里讲的内容，就能在开发中灵活应用。 学习数据结构和算法的过程，是非常好的思维训练的过程，所以，千万不要被动地记忆，要多辩证地思考，多问为什么。如果你一直这么坚持做，你会发现，等你学完之后，写代码的时候就会不由自主地考虑到很多性能方面的事情，时间复杂度、空间复杂度非常高的垃圾代码出现的次数就会越来越少。你的编程内功就真正得到了修炼。 一些可以让你事半功倍的学习技巧 前面我给你划了学习的重点，作为一个过来人，现在我就给你分享一下，学习的一些技巧。掌握了这些技巧，可以让你化被动为主动，学起来更加轻松，更加有动力！ 边学边练，适度刷题 “边学边练”这一招非常有用。建议你每周花1～2个小时的时间，集中把这周的三节内容涉及的数据结构和算法，全都自己写出来，用代码实现一遍。这样一定会比单纯地看或者听的效果要好很多！ 有面试需求的同学，可能会问了，那我还要不要去刷题呢？ 我个人的观点是可以“适度”刷题，但一定不要浪费太多时间在刷题上。我们学习的目的还是掌握，然后应用。除非你要面试Google、Facebook这样的公司，它们的算法题目非常非常难，必须大量刷题，才能在短期内提升应试正确率。如果是应对国内公司的技术面试，即便是BAT这样的公司，你只要彻底掌握这个专栏的内容，就足以应对。 多问、多思考、多互动 学习最好的方法是，找到几个人一起学习，一块儿讨论切磋，有问题及时寻求老师答疑。但是，离开大学之后，既没有同学也没有老师，这个条件就比较难具备了。 打怪升级学习法 学习的过程中，我们碰到最大的问题就是，坚持不下来。是的，很多基础课程学起来都非常枯燥。为此，我自己总结了一套“打怪升级学习法”。 游戏你肯定玩过吧？为什么很多看起来非常简单又没有乐趣的游戏，你会玩得不亦乐乎呢？这是因为，当你努力打到一定级别之后，每天看着自己的经验值、战斗力在慢慢提高，那种每天都在一点一点成长的成就感就不由自主地产生了。 知识需要沉淀，不要想试图一下子掌握所有 在学习的过程中，一定会碰到“拦路虎”。如果哪个知识点没有怎么学懂，不要着急，这是正常的。因为，想听一遍、看一遍就把所有知识掌握，这肯定是不可能的。学习知识的过程是反复迭代、不断沉淀的过程。 这些内容是我根据平时的学习和工作、面试经验积累，精心筛选出来的。只要掌握这些内容，应付日常的面试、工作，基本不会有问题。 以上内容出自近70000+程序员的算法课堂《数据结构与算法之美》，这个专栏是市面上唯一一门真正适用于工程师的专栏，专栏中列举大量实际软件开发中的场景，给你展示如何利用数据结构和算法解决真实的问题。整个专栏会涵盖100 多个算法真实项目场景案例，更难得的是它跟市面上晦涩的算法书籍不同的是，还手绘了一些清晰易懂的详解图（总共有 300 多张）。 手绘图—出自《数据结构与算法之美》 专栏已经更新完毕，72 篇文章，27 万字，这个专栏作者并非只是单纯地把某个知识点讲清楚，而是结合作者的理解、实践和经验来讲解，我相信它是一个跟所有国内、国外经典书籍都不一样的专栏，一个可以长期影响一些人的专栏。 这个专栏不会像《算法导论》那样，里面有非常复杂的数学证明和推理。作者会由浅入深，从概念到应用，一点一点给你解释清楚。你只要有高中数学水平，就完全可以学习。 当然，当然希望你最好有些编程基础，如果有项目经验就更好了。这样给你讲数据结构和算法如何提高效率、如何节省存储空间，你就会有很直观的感受。因为，对于每个概念和实现过程，作者都会从实际场景出发，不仅教你“是什么”，还会教你“为什么”，并且告诉你遇到同类型问题应该“怎么做”。 强烈推荐这个专栏给想攻克算法的同学，它改变了无数对算法恐惧的同学，我整理了一些专栏的评价给大家参考。

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

前言 这期我想写很久了，但是因为时间的原因一直拖到了现在，我以为一两天就写完了，结果从构思到整理资料，再到写出来用了差不多一周的时间吧。 你们也知道丙丙一直都是创作鬼才来的，所以我肯定不会一本正经的写，我想了好几个切入点，最后决定用一个完整的电商系统作为切入点，带着大家看看，我们需要学些啥，我甚至还收集配套视频和资料，暖男石锤啊，这期是呕心沥血之作，不要白嫖了。 正文 在写这个文章之前，我花了点时间，自己臆想了一个电商系统，基本上算是麻雀虽小五脏俱全，我今天就用它开刀，一步步剖析，我会讲一下我们可能会接触的技术栈可能不全，但是够用，最后给个学习路线。 Tip：请多欣赏一会，每个点看一下，看看什么地方是你接触过的，什么技术栈是你不太熟悉的，我觉得还算是比较全的，有什么建议也可以留言给我。 不知道大家都看了一下没，现在我们就要庖丁解牛了，我从上到下依次分析。 前端 你可能会会好奇，你不是讲后端学习路线嘛，为啥还有前端的部分，我只能告诉你，傻瓜，肤浅。 我们可不能闭门造车，谁告诉你后端就不学点前端了？ 前端现在很多也了解后端的技术栈的，你想我们去一个网站，最先接触的，最先看到的是啥？ 没错就是前端，在大学你要是找不到专门的前端同学，去做系统肯定也要自己顶一下前端的，那我觉得最基本的技术栈得熟悉和了解吧，丙丙现在也是偶尔会开发一下我们的管理系统主要是VUE和React。 在这里我列举了我目前觉得比较简单和我们后端可以了解的技术栈，都是比较基础的。 作为一名后端了解部分前端知识还是很有必要的，在以后开发的时候，公司有前端那能帮助你前后端联调更顺畅，如果没前端你自己也能顶一下简单的页面。 HTML、CSS、JS、Ajax我觉得是必须掌握的点，看着简单其实深究或者去操作的话还是有很多东西的，其他作为扩展有兴趣可以了解，反正入门简单，只是精通很难很难。 在这一层不光有这些还有Http协议和Servlet，request、response、cookie、session这些也会伴随你整个技术生涯，理解他们对后面的你肯定有不少好处。 Tip：我这里最后删除了JSP相关的技术，我个人觉得没必要学了，很多公司除了老项目之外，新项目都不会使用那些技术了。 前端在我看来比后端难，技术迭代比较快，知识好像也没特定的体系，所以面试大厂的前端很多朋友都说难，不是技术多难，而是知识多且复杂，找不到一个完整的体系，相比之下后端明朗很多，我后面就开始讲后端了。 网关层： 互联网发展到现在，涌现了很多互联网公司，技术更新迭代了很多个版本，从早期的单机时代，到现在超大规模的互联网时代，几亿人参与的春运，几千亿成交规模的双十一，无数互联网前辈的造就了现在互联网的辉煌。 微服务，分布式，负载均衡等我们经常提到的这些名词都是这些技术在场景背后支撑。 单机顶不住，我们就多找点服务器，但是怎么将流量均匀的打到这些服务器上呢？ 负载均衡，LVS 我们机器都是IP访问的，那怎么通过我们申请的域名去请求到服务器呢？ DNS 大家刷的抖音，B站，快手等等视频服务商，是怎么保证同时为全国的用户提供快速的体验？ CDN 我们这么多系统和服务，还有这么多中间件的调度怎么去管理调度等等？ zk 这么多的服务器，怎么对外统一访问呢，就可能需要知道反向代理的服务器。 Nginx 这一层做了反向负载、服务路由、服务治理、流量管理、安全隔离、服务容错等等都做了，大家公司的内外网隔离也是这一层做的。 我之前还接触过一些比较有意思的项目，所有对外的接口都是加密的，几十个服务会经过网关解密，找到真的路由再去请求。 这一层的知识点其实也不少，你往后面学会发现分布式事务，分布式锁，还有很多中间件都离不开zk这一层，我们继续往下看。 服务层： 这一层有点东西了，算是整个框架的核心，如果你跟我帅丙一样以后都是从事后端开发的话，我们基本上整个技术生涯，大部分时间都在跟这一层的技术栈打交道了，各种琳琅满目的中间件，计算机基础知识，Linux操作，算法数据结构，架构框架，研发工具等等。 我想在看这个文章的各位，计算机基础肯定都是学过的吧，如果大学的时候没好好学，我觉得还是有必要再看看的。 为什么我们网页能保证安全可靠的传输，你可能会了解到HTTP，TCP协议，什么三次握手，四次挥手。 还有进程、线程、协程，什么内存屏障，指令乱序，分支预测，CPU亲和性等等，在之后的编程生涯，如果你能掌握这些东西，会让你在遇到很多问题的时候瞬间get到点，而不是像个无头苍蝇一样乱撞（然而丙丙还做得不够）。 了解这些计算机知识后，你就需要接触编程语言了，大学的C语言基础会让你学什么语言入门都会快点，我选择了面向对象的JAVA，但是也不知道为啥现在还没对象。 JAVA的基础也一样重要，面向对象（包括类、对象、方法、继承、封装、抽象、 多态、消息解析等），常见API，数据结构，集合框架，设计模式（包括创建型、结构型、行为型），多线程和并发，I/O流，Stream，网络编程你都需要了解。 代码会写了，你就要开始学习一些能帮助你把系统变得更加规范的框架，SSM可以会让你的开发更加便捷，结构层次更加分明。 写代码的时候你会发现你大学用的Eclipse在公司看不到了，你跟大家一样去用了IDEA，第一天这是什么玩意，一周后，真香，但是这玩意收费有点贵，那免费的VSCode真的就是不错的选择了。 代码写的时候你会接触代码的仓库管理工具maven、Gradle，提交代码的时候会去写项目版本管理工具Git。 代码提交之后，发布之后你会发现很多东西需要自己去服务器亲自排查，那Linux的知识点就可以在里面灵活运用了，查看进程，查看文件，各种Vim操作等等。 系统的优化很多地方没优化的空间了，你可能会尝试从算法，或者优化数据结构去优化，你看到了HashMap的源码，想去了解红黑树，然后在算法网上看到了二叉树搜索树和各种常见的算法问题，刷多了，你也能总结出精华所在，什么贪心，分治，动态规划等。 这么多个服务，你发现HTTP请求已经开始有点不满足你的需求了，你想开发更便捷，像访问本地服务一样访问远程服务，所以我们去了解了Dubbo，Spring cloud。 了解Dubbo的过程中，你发现了RPC的精华所在，所以你去接触到了高性能的NIO框架，Netty。 代码写好了，服务也能通信了，但是你发现你的代码链路好长，都耦合在一起了，所以你接触了消息队列，这种异步的处理方式，真香。 他还可以帮你在突发流量的时候用队列做缓冲，但是你发现分布式的情况，事务就不好管理了，你就了解到了分布式事务，什么两段式，三段式，TCC，XA，阿里云的全局事务服务GTS等等。 分布式事务的时候你会想去了解RocketMQ，因为他自带了分布式事务的解决方案，大数据的场景你又看到了Kafka。 我上面提到过zk，像Dubbo、Kafka等中间件都是用它做注册中心的，所以很多技术栈最后都组成了一个知识体系，你先了解了体系中的每一员，你才能把它们联系起来。 服务的交互都从进程内通信变成了远程通信，所以性能必然会受到一些影响。 此外由于很多不确定性的因素，例如网络拥塞、Server 端服务器宕机、挖掘机铲断机房光纤等等，需要许多额外的功能和措施才能保证微服务流畅稳定的工作。 **Spring Cloud **中就有 Hystrix 熔断器、Ribbon客户端负载均衡器、Eureka注册中心等等都是用来解决这些问题的微服务组件。 你感觉学习得差不多了，你发现各大论坛博客出现了一些前沿技术，比如容器化，你可能就会去了解容器化的知识，像**Docker，Kubernetes（K8s）**等。 微服务之所以能够快速发展，很重要的一个原因就是：容器化技术的发展和容器管理系统的成熟。 这一层的东西呢其实远远不止这些的，我不过多赘述，写多了像个劝退师一样，但是大家也不用慌，大部分的技术都是慢慢接触了，工作中慢慢去了解，去深入的。 好啦我们继续沿着图往下看，那再往下是啥呢？ 数据层： 数据库可能是整个系统中最值钱的部分了，在我码文字的前一天，刚好发生了微盟程序员删库跑路的操作，删库跑路其实是我们在网上最常用的笑话，没想到还是照进了现实。 这里也提一点点吧，36小时的故障，其实在互联网公司应该是个笑话了吧，权限控制没做好类似rm -rf 、fdisk、drop等等这样的高危命令是可以实时拦截掉的，备份，全量备份，增量备份，延迟备份，异地容灾全部都考虑一下应该也不至于这样，一家上市公司还是有点点不应该。 数据库基本的事务隔离级别，索引，SQL，主被同步，读写分离等都可能是你学的时候要了解到的。 上面我们提到了安全，不要把鸡蛋放一个篮子的道理大家应该都知道，那分库的意义就很明显了，然后你会发现时间久了表的数据大了，就会想到去接触分表，什么TDDL、Sharding-JDBC、DRDS这些插件都会接触到。 你发现流量大的时候，或者热点数据打到数据库还是有点顶不住，压力太大了，那非关系型数据库就进场了，Redis当然是首选，但是MongoDB、memcache也有各自的应用场景。 Redis使用后，真香，真快，但是你会开始担心最开始提到的安全问题，这玩意快是因为在内存中操作，那断点了数据丢了怎么办？你就开始阅读官方文档，了解RDB，AOF这些持久化机制，线上用的时候还会遇到缓存雪崩击穿、穿透等等问题。 单机不满足你就用了，他的集群模式，用了集群可能也担心集群的健康状态，所以就得去了解哨兵，他的主从同步，时间久了Key多了，就得了解内存淘汰机制…… 他的大容量存储有问题，你可能需要去了解Pika…. 其实远远没完，每个的点我都点到为止，但是其实要深究每个点都要学很久，我们接着往下看。 实时/离线/大数据 等你把几种关系型非关系型数据库的知识点，整理清楚后，你会发现数据还是大啊，而且数据的场景越来越多多样化了，那大数据的各种中间件你就得了解了。 你会发现很多场景，不需要实时的数据，比如你查你的支付宝去年的，上个月的账单，这些都是不会变化的数据，没必要实时，那你可能会接触像ODPS这样的中间件去做数据的离线分析。 然后你可能会接触Hadoop系列相关的东西，比如于Hadoop（HDFS）的一个数据仓库工具Hive，是建立在 Hadoop 文件系统之上的分布式面向列的数据库HBase 。 写多的场景，适合做一些简单查询，用他们又有点大材小用，那Cassandra就再合适不过了。 离线的数据分析没办法满足一些实时的常见，类似风控，那Flink你也得略知一二，他的窗口思想还是很有意思。 数据接触完了，计算引擎Spark你是不是也不能放过…… 搜索引擎： 传统关系型数据库和NoSQL非关系型数据都没办法解决一些问题，比如我们在百度，淘宝搜索东西的时候，往往都是几个关键字在一起一起搜索东西的，在数据库除非把几次的结果做交集，不然很难去实现。 那全文检索引擎就诞生了，解决了搜索的问题，你得思考怎么把数据库的东西实时同步到ES中去，那你可能会思考到logstash去定时跑脚本同步，又或者去接触伪装成一台MySQL从服务的Canal，他会去订阅MySQL主服务的binlog，然后自己解析了去操作Es中的数据。 这些都搞定了，那可视化的后台查询又怎么解决呢？Kibana，他他是一个可视化的平台，甚至对Es集群的健康管理都做了可视化，很多公司的日志查询系统都是用它做的。 学习路线 看了这么久你是不是发现，帅丙只是一直在介绍每个层级的技术栈，并没说到具体的一个路线，那是因为我想让大家先有个认知或者说是扫盲吧，我一样用脑图的方式汇总一下吧，如果图片被平台二压了。 资料/学习网站 Tip：本来这一栏有很多我准备的资料的，但是都是外链，或者不合适的分享方式，博客的运营小姐姐提醒了我，所以大家去公众号回复【路线】好了。 絮叨 如果你想去一家不错的公司，但是目前的硬实力又不到，我觉得还是有必要去努力一下的，技术能力的高低能决定你走多远，平台的高低，能决定你的高度。 如果你通过努力成功进入到了心仪的公司，一定不要懈怠放松，职场成长和新技术学习一样，不进则退。 丙丙发现在工作中发现我身边的人真的就是实力越强的越努力，最高级的自律，享受孤独（周末的歪哥）。 总结 我提到的技术栈你想全部了解，我觉得初步了解可能几个月就够了，这里的了解仅限于你知道它，知道他是干嘛的，知道怎么去使用它，并不是说深入了解他的底层原理，了解他的常见问题，熟悉问题的解决方案等等。 你想做到后者，基本上只能靠时间上的日积月累，或者不断的去尝试积累经验，也没什么速成的东西，欲速则不达大家也是知道的。 技术这条路，说实话很枯燥，很辛苦，但是待遇也会高于其他一些基础岗位。 所实话我大学学这个就是为了兴趣，我从小对电子，对计算机都比较热爱，但是现在打磨得，现在就是为了钱吧，是不是很现实？若家境殷实，谁愿颠沛流离。 但是至少丙丙因为做软件，改变了家庭的窘境，自己日子也向小康一步步迈过去。 说做程序员改变了我和我家人的一生可能夸张了，但是我总有一种下班辈子会因为我选择走这条路而改变的错觉。 我是敖丙，一个在互联网苟且偷生的工具人。 创作不易，本期硬核，不想被白嫖，各位的「三连」就是丙丙创作的最大动力，我们下次见！ 本文 GitHub https://github.com/JavaFamily 已经收录，有大厂面试完整考点，欢迎Star。 该回答来自：敖丙

　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年从日韩经过的船所收的一个费用 答案来源网络，供参考，希望对您有帮助

回2楼啊里新人的帖子 在日常的业务开发中，常见使用到索引的地方大概有两类： 第一类.做业务约束需求，比如需要保证表中每行的单个字段或者某几个组合字段是唯一的，则可以在表中创建唯一索引; 比如：需要保证test表中插入user_id字段的值不能出现重复，则在设计表的时候，就可以在表中user_id字段上创建一个唯一索引： CREATE TABLE `test` (   `id` int(11) NOT NULL AUTO_INCREMENT,   `user_id` int(11) NOT NULL,   `gmt_create` datetime DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `uk_userid` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ; 第二类.提高SQL语句执行速度，可以根据SQL语句的查询条件在表中创建合适的索引，以此来提升SQL语句的执行速度； 此过程好比是去图书找一本书，最慢的方法就是从图书馆的每一层楼每一个书架一本本的找过去；快捷一点的方法就是先通过图书检索来确认这一本书在几楼那个书架上，然后直接去找就可以了；当然创建这个索引也需要有一定的代价，需要存储空间来存放，需要在数据行插入，更新，删除的时候维护索引： 例如： CREATE TABLE `test_record` (   `id` int(11) NOT NULL AUTO_INCREMENT,   `user_id` int(11) NOT NULL,   `gmt_create` datetime DEFAULT NULL,   PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=5635996 DEFAULT CHARSET=utf8 该表有500w的记录，我需要查询20:00后插入的记录有多少条记录： mysql> select count(*) from test_record where gmt_create>'2014-12-17 20:00:00'; +----------+ | count(*) | +----------+ |        1 | +----------+ 1 row in set (1.31 sec) 可以看到查询耗费了1.31秒返回了1行记录，如果我们在gmt_create字段上添加索引： mysql> alter table test_record add index ind_gmt_create(gmt_create); Query OK, 0 rows affected (21.87 sec) Records: 0  Duplicates: 0  Warnings: 0 mysql> select count(*) from test_record where gmt_create>'2014-12-17 20:00:00'; +----------+ | count(*) | +----------+ |        1 | +----------+ 1 row in set (0.01 sec) 查询只消耗了0.01秒中就返回了记录. 总的来说，为SQL语句（select，update，delete）创建必要的索引是必须的，这样虽然有一定的性能和空间消耗，但是是值得，尤其是在大并发的请求下，大量的数据被扫描造成系统IO和CPU资源消耗完，进而导致整个数据库不可服务. ------------------------- 怎么学好数据库是一个比较大题目，数据库不仅仅是写SQL那么简单，即使知道了SQL怎么写，还需要很清楚的知道这条SQL他大概扫描了多少数据，返回多少数据，是否需要创建索引。至于SQL优化是一个比较专业的技术活，但是可以通过学习是可以掌握的，你可以把一条sql从执行不出来优化到瞬间完成执行，这个过程的成就感是信心满满的。学习的方法可以有以下一些过程：1、自己查资料，包括书本，在线文档，google，别人的总结等等，试图自己解决2、多做实验，证明自己的想法以及判断3、如果实在不行，再去论坛问，或者问朋友4、如果问题解决了，把该问题的整个解决方法记录下来，以备后来的需要5、多关注别人的问题，或许以后自己就遇到了，并总是试图去多帮助别人6、习惯从多个方面去考虑问题，并且养成良好的总结习惯 下面是一些国内顶级数据库专家学习数据库的经验分享给大家： http://www.eygle.com/archives/2005/08/ecinieoracleouo.html 其实学习任何东西都是一样，没有太多的捷径可走，必须打好了坚实的基础，才有可以在进一步学习中得到快速提高。王国维在他的《人间词话》中曾经概括了为学的三种境界，我在这里套用一下： 古今之成大事业、大学问者，罔不经过三种之境界。"昨夜西风凋碧树。独上高楼，望尽天涯路。"此第一境界也。"衣带渐宽终不悔，为伊消得人憔悴。"此第二境界也。"众里寻他千百度，蓦然回首，那人却在灯火阑珊处。"此第三境界也。 学习Oracle，这也是你必须经历的三种境界。 第一层境界是说，学习的路是漫漫的，你必须做好充分的思想准备，如果半途而废还不如不要开始。 这里，注意一个"尽"字，在开始学习的过程中，你必须充分阅读Oracle的基础文档，概念手册、管理手册、备份恢复手册等（这些你都可以在http://tahiti.oracle.com 上找到）；OCP认证的教材也值得仔细阅读。打好基础之后你才具备了进一步提升的能力，万丈高楼都是由地而起。 第二层境界是说，尽管经历挫折、打击、灰心、沮丧，也都要坚持不放弃，具备了基础知识之后，你可以对自己感兴趣或者工作中遇到的问题进行深入的思考，由浅入深从来都不是轻而易举的，甚至很多时候你会感到自己停滞不前了，但是不要动摇，学习及理解上的突破也需要时间。 第三次境界是说，经历了那么多努力以后，你会发现，那苦苦思考的问题，那百思不得其解的算法原理，原来答案就在手边，你的思路豁然开朗，宛如拨云见月。这个时候，学习对你来说，不再是个难题，也许是种享受，也许成为艺术。 所以如果你想问我如何速成，那我是没有答案的。 不经一番寒彻骨，哪得梅花扑鼻香。 当然这三种境界在实际中也许是交叉的，在不断的学习中，不断有蓦然回首的收获。 我自己在学习的过程中，经常是采用"由点及面法"。 当遇到一个问题后，一定是深入下去，穷究根本，这样你会发现，一个简单的问题也必定会带起一大片的知识点，如果你能对很多问题进行深入思考和研究，那么在深处，你会发现，这些面逐渐接合，慢慢的延伸到oracle的所有层面，逐渐的你就能融会贯通。这时候，你会主动的去尝试全面学习Oracle，扫除你的知识盲点，学习已经成为一种需要。 由实践触发的学习才最有针对性，才更能让你深入的理解书本上的知识，正所谓：" 纸上得来终觉浅，绝知此事要躬行"。实践的经验于我们是至为宝贵的。 如果说有，那么这，就是我的捷径。 想想自己，经常是"每有所获，便欣然忘食"， 兴趣才是我们最好的老师。 Oracle的优化是一门学问，也是一门艺术，理解透彻了，你会知道，优化不过是在各种条件之下做出的均衡与折中。 内存、外存；CPU、IO...对这一切你都需要有充分的认识和相当的了解，管理数据库所需要的知识并不单纯。 作为一个数据库管理人员，你需要做的就是能够根据自己的知识以及经验在各种复杂情况下做出快速正确的判断。当问题出现时，你需要知道使用怎样的手段发现问题的根本；找到问题之后，你需要运用你的知识找到解决问题的方法。 这当然并不容易，举重若轻还是举轻若重，取决于你具备怎样的基础以及经验积累。 在网络上，Howard J. Rogers最近创造了一个新词组:Voodoo Tuning，用以形容那些没有及时更新自己的知识技能的所谓的Oracle技术专家。由于知识的陈旧或者理解的肤浅，他们提供的很多调整建议是错误的、容易使人误解的，甚至是荒诞的。他们提供的某些建议在有些情况下也许是正确的，如果你愿意回到Oracle5版或者6版的年代；但是这些建议在Oracle7.0,8.0 或者 Oracle8i以后往往是完全错误的。 后来基于类似问题触发了互联网内Oracle顶级高手的一系列深入讨论，TOM、Jonathan Lewis、HJR等人都参与其中，在我的网站上(www.eygle.com )上对这些内容及相关链接作了简要介绍，有兴趣的可以参考。 HJR给我们提了很好的一个提示:对你所需要调整的内容，你必须具有充分的认识，否则你做出的判断就有可能是错误的。 这也是我想给自己和大家的一个建议: 学习和研究Oracle，严谨和认真必不可少。 当然 你还需要勤奋，我所熟悉的在Oracle领域有所成就的技术人员，他们共同的特点就是勤奋。 如果你觉得掌握的东西没有别人多，那么也许就是因为，你不如别人勤奋。 要是你觉得这一切过于复杂了，那我还有一句简单的话送给大家: 不积跬步，无以至千里。学习正是在逐渐积累过程中的提高。 现在Itpub给我们提供了很好的交流场所，很多问题都可以在这里找到答案，互相讨论，互相学习。这是我们的幸运，我也因此非常感谢这个网络时代。 参考书籍： 如果是一个新人可以先买一些基本的入门书籍，比如MySQL：《 深入浅出MySQL——数据库开发、优化与管理维护 》，在进阶一点的就是《 高性能MySQL（第3版） 》 oracle的参考书籍： http://www.eygle.com/archives/2006/08/oracle_fundbook_recommand.html 最后建议不要在数据库中使用外键，让应用程序来保证。 ------------------------- Re:回 9楼(千鸟) 的帖子 我有一个问题想问问，现在在做一个与图书有关的项目，其中有一个功能是按图书书名搜索相似图书列表，问题不难，但是想优化一下，有如下问题想请教一下： 1、在图书数据库数据表的书名字段里，按图书书名进行关键字搜索，如何快速搜索相关的图书？   现在由于数据不多，直接用的like模糊查找验证功能而已； 如果数据量不大，是可以在数据库中完成搜索的，可以在搜索字段上创建索引，然后进行搜索查询： CREATE TABLE `book` (   `book_id` int(11) NOT NULL AUTO_INCREMENT,   `book_name` varchar(100) NOT NULL,   .............................   PRIMARY KEY (`book_id`),   KEY `ind_name` (`book_name`) ) ENGINE=InnoDB select book.*  from book , (select book_id from book where book_name like '%算法%')  book_search_id  where book.book_id=book_search_id.book_id; 但是当数据量变得很大后，就不在适合了，可以采用一些其他的第三方搜索技术比如sphinx； 2、如何按匹配的关键度进行快速排序？比如搜索“算法”，有一本书是《算法》，另一本书是《算法设计》，要求前者排在更前面。 现在的排序是根据数据表中的主键序号id进行的排序，没有达到想要的效果。 root@127.0.0.1 : test 15:57:12> select book_id,book_name from book_search where book_name like '%算%' order by book_name; +---------+--------------+ | book_id | book_name    | +---------+--------------+ |       2 | 算法       | |       1 | 算法设计 | ------------------------- 回 10楼(大黑豆) 的帖子 模糊查询分为半模糊和全模糊，也就是： select * from book where name like 'xxx%';(半模糊) select * from book where name like '%xxx%';(全模糊) 半模糊可以可以使用到索引，全模糊在上面场景是不能使用到索引的，但可以进行一些改进，比如： select book.*  from book , (select book_id from book where book_name like '%算法%')  book_search_id   where book.book_id=book_search_id.book_id; 注意这里book_id是主键，同时在book_name上创建了索引 上面的sql语句可以利用全索引扫描来完成优化，但是性能不会太好；特别在数据量大，请求频繁的业务场景下不要在数据库进行模糊查询； 非得使用数据库的话 ，建议不要在生产库进行查询，可以在只读节点进行查询，避免查询造成主业务数据库的资源消耗完，导致故障. 可以使用一些开源的搜索引擎技术，比如sphinx. ------------------------- 回 11楼(蓝色之鹰) 的帖子 我想问下,sql优化一般从那几个方面入手？多表之间的连接方式：Nested Loops，Hash Join 和 Sort Merge Join，是不是Hash Join最优连接？ SQL优化需要了解优化器原理，索引的原理，表的存储结构，执行计划等，可以买一本书来系统的进行学习，多多实验； 不同的数据库优化器的模型不一样，比如oracle支持NL，HJ，SMJ，但是mysql只支持NL，不通的连接方式适用于不同的应用场景； NL：对于被连接的数据子集较小的情况，嵌套循环连接是个较好的选择 HJ：对于列连接是做大数据集连接时的常用方式 SMJ：通常情况下散列连接的效果都比排序合并连接要好，然而如果行源已经被排过序，在执行排序合并连接时不需要再排序了，这时排序合并连接的性能会优于散列连接 ------------------------- Re:回 19楼(原远) 的帖子 有个问题：分类表TQueCategory，问题表TQuestion（T-SQL) CREATE TABLE TQueCategory ( ID INT IDENTITY(1,1) PRIMARY KEY,        --问题分类ID NAME VARCHAR(20)        --问题分类名称 ) CREATE TABLE TQuestion ( ID INT IDENTITY(1,1) PRIMARY KEY,        --问题ID CateID INT NOT NULL,        --问题分类ID TITLE VARCHAR(50),        --问题标题 CONTENT VARCHAR(500)        --问题内容 ) 当前要统计某个分类下的问题数，有两种方式： 1.每次统计，在TQuestion通过CateID进行分组统计 SELECT CateID,COUNT(1) AS QueNum FROM TQuestion GROUP BY CateID WHERE 1=1 2.在TQueCategory表增加字段QueNum，用于标识该分类下的问题数量 ALTER TABLE TQueCategory ADD QueNum INT SELECT CateID,QueNum FROM TQueCategory 问：在哪种业务应用场景下采用上面哪种方式性能比较好，为什么？ ############################################################################################### 方案 一 需要对 TQuestion 的 CateID字段 进行分组 ，可以在 CateID上创建一个索引，这样就可以索引扫描来完成查询； 方案 二 需要对 TQueCategory 进行扫描就可以得出结果，但是必须在问题表有插入，删除的时候维护quenum数量； 单单从SQL的性能来看， 分类表的数量应该是远远小于问题表的数量的，所以方案二的性能会比较好； 但是如果 TQuestion 的插入非常频繁的话，会带来对 TQueCategory的频繁更新，一次 TQuestion 的 insert或deleted就会带来一次 TQueCategory 的update，这个代价其实是蛮高的； 如果这个分类统计的查询不是非常频繁的话，建议还是使用方案一； 同时还可能还会其他的业务逻辑统计需求（例如： CateID +时间），这个时候在把逻辑放到 TQueCategory就不合适了。 ------------------------- 回 20楼(原远) 的帖子 经验之谈，仅供参考 使用外键在开发上确实省去了很多功夫，但是把业务逻辑交由数据库来完成，对后期的维护来说是很麻烦的事情，不利于维护. ------------------------- 回 21楼(玩站网) 的帖子 无关技术方面： 咨询一下，现在mysql新的版本，5.5.45后貌似修改了开源协议。 是否意味着今后我们商业化使用mysql将受到限制？ 如果甲骨文真周到那一步，rds是否会受到影响？ 一个疑惑： 为什么很少见到有人用mysql正则匹配？性能不好还是什么原因？ ######################################## MySQL有商业版 和 社区版，RDS的MySQL采用开源的社区版进行改进，由专门的RDS MySQL源码团队来维护，国内TOP 10的mysql源码贡献者大部分都在RDS，包括了@丁奇 ，@彭立勋 ，@印风 等； 不在数据库中做业务计算，是保证数据库运行稳定的一个好的设计经验； 是否影响性能与你的sql的执行频率，需要参与的计算数据量相关，当然了还包括数据库所在主机的IO，cpu，内存等资源，离开了这些谈性能是没有多大意义的； ------------------------- 回 22楼(比哥) 的帖子 分页该怎么优化才行？？？ ######################### 可以参考这个链接，里面有很多的最佳实践，其中就包括了分页语句的优化： http://bbs.aliyun.com/read/168647.html?spm=5176.7114037.1996646101.1.celwA1&pos=1 普通写法： select  *  from t where sellerid=100 limit 100000，20 普通limit M，N的翻页写法，往往在越往后翻页的过程中速度越慢，原因 mysql会读取表中的前M+N条数据，M越大，性能就越差： 优化写法： select t1.* from  t t1,             (select id from t  sellerid=100 limit 100000，20) t2 where t1.id=t2.id; 优化后的翻页写法，先查询翻页中需要的N条数据的主键id，在根据主键id 回表查询所需要的N条数据，此过程中查询N条数据的主键ID在索引中完成 注意：需要在t表的sellerid字段上创建索引 create index ind_sellerid on t(sellerid); 案例： user_A (21:42:31): 这个sql该怎么优化，执行非常的慢： | Query   |   51 | Sending data | select id, ... from t_buyer where sellerId = 765922982 and gmt_modified >= '1970-01-01 08:00:00' and gmt_modified <= '2013-06-05 17:11:31' limit 255000, 5000 SQL改写：selectt2.* from (selectid from t_buyer where sellerId = 765922982   andgmt_modified >= '1970-01-01 08:00:00'   andgmt_modified <= '2013-06-05 17:11:31' limit255000, 5000）t1,t_buyer t2 where t1.id=t2.id index：seller_id,gmt_modified user_A(21:58:43): 好像很快啊。神奇，这个原理是啥啊。牛！！！ user_A(21:59:55): 5000 rows in set (4.25 sec)， 前面要90秒。 ------------------------- 回 27楼(板砖大叔) 的帖子 这里所说的索引都是普通的b-tree索引，mysql，sqlserver，oracle 的关系数据库都是默认支持的； ------------------------- 回 32楼(veeeye) 的帖子 可以详细说明一下“最后建议不要在数据库中使用外键，让应用程序来保证。 ”的原因吗？我们公司在项目中经常使用外键，用程序来保证不是相对而言更加复杂了吗？ 这里的不建议使用外键，主要考虑到 ： 第一.维护成本上，把一些业务逻辑交由数据库来保证，当业务需求发生改动的时候，需要同时考虑应用程序和数据库，有时候一些数据库变更或者bug，可能会导致外键的失效；同时也给数据库的管理人员带来维护的麻烦，不便于管理。 第二.性能上考虑，当大量数据写入的时候，外键肯定会带来一定的性能损耗，当出现这样的问题时候，再来改造去除外键，真的就不值得了； 最后，不在数据库中参与业务的计算（存储过程，函数，触发器，外键），是保证数据库运行稳定的一个好的最佳实践。 ------------------------- 回 33楼(优雅的固执) 的帖子 ReDBA专家门诊一期：索引与sql优化 十分想请大师分享下建立索引的经验 我平时简历索引是这样的 比如订单信息的话 建立 订单号  唯一聚集索引 其他的比如   客户编号 供应商编号 商品编号 这些建立非聚集不唯一索引   ################################################## 建立索引，需要根据你的SQL语句来进行创建，不是每一个字段都需要进行创建，也不是一个索引都不创建,，可以把你的SQL语句，应用场景发出来看看。 索引的创建确实是一个非常专业的技术活，需要掌握：表的存储方式，索引的原理，数据库的优化器，统计信息，最后还需要能够读懂数据库的执行计划，以此来判断索引是否创建正确； 所以需要进行系统的学习才能掌握，附件是我在2011年的时候的一次公开课的ppt，希望对你有帮助，同时可以把你平时遇到的索引创建的疑惑发到论坛上来，大家可以一起交流。 ------------------------- 回 30楼(几几届) 的帖子 我也是这样，简单的会，仔细写也会写出来，但是就是不知道有没有更快或者更好的 #################################################### 多写写SQL，掌握SQL优化的方法，自然这些问题不在话下了。 ------------------------- 回 40楼(小林阿小林) 的帖子 mysql如何查询需要优化的语句，比如慢查询的步奏，如何找出需要通知程序员修改或者优化的sql语句 ############################################################ 可以将mysql的慢日志打开，就可以记录执行时间超过指定阀值的慢SQL到本地文件或者数据库的slow_log表中； 在RDS中默认是打开了慢日志功能的：long_query_time=1，表示会记录执行时间>=1秒的慢sql； 如何快速找到mysql瓶颈： 简单一点的方法，可以通过监控mysql所在主机的性能（CPU，IO，load等）以及mysql本身的一些状态值（connections，thread running，qps，命中率等）； RDS提供了完善的数据库监控体系，包括了CPU，IOPS，Disk，Connections，QPS，可以重点关注cpu，IO，connections，disk 4个 指标； cpu，io，connections主要体现在了性能瓶颈，disk主要体现了空间瓶颈； 有时候一条慢sql语句的频繁调用，也可能导致整个实例的cpu，io，connections达到100%；也有可能一条排序的sql语句，消耗大量的临时空间，导致实例的空间消耗完。 ------------------------- 下面是分析一个cpu 100%的案例分析：该实例的cpu已经到达100% 查看当前数据库的活动会话信息：当前数据库有较多的活跃线程在数据库中执行查看当前数据库正在执行的sql： 可以看到这条sql执行的非常缓慢：[tr=rgb(100, 204, 255)]delete from task_process where task_id='1801099' 查看这个表的索引： CREATE TABLE `task_process` (  `id` int(11) NOT NULL AUTO_INCREMENT,    ................  `task_id` int(11) NOT NULL DEFAULT '0' COMMENT '??????id',   ................  PRIMARY KEY (`id`),  KEY `index_over_task` (`is_over`,`task_id`),  KEY `index_over` (`is_over`,`is_auto`) USING BTREE,  KEY `index_process_sn` (`process_sn`,`is_over`) USING BTREE) ENGINE=InnoDB AUTO_INCREMENT=32129710； 可以看到这个表有3KW的数据，但是没有task_id字段开头的索引，导致该sql语句删除需要进行全表扫描： 在我们的诊断报告中已经将该sql语句捕获到，同时给你提出该怎样进行索引的添加。 广告：诊断报告将会在1月底发布到控制台，到时候用户可以直接查看诊断建议，来完成你的数据库优化。 ------------------------- 回 45楼(dentrite) 的帖子 datetime和int都是占用数据库4个字节，所以在空间上没有什么差别；但是为了可读性，建议还是使用datetime数据类型。 ------------------------- 回 48楼(yuantel) 的帖子 麻烦把ecs_brand和ecs_goods的表结构发出来一下看看 。 ------------------------- 回 51楼(小林阿小林) 的帖子 普通的 ECS服务器上目前还没有这样的慢SQL索引建议的工具。 不过后续有IDBCloud将会集成这样的sql诊断功能，使用他来管理ECS上的数据库就可以使用这样的功能了 。

转自：阿飞的博客 一、数据库技术选型的思考维度 我们做选型的时候首先要问： 谁选型？是负责采购的同学、 DBA 还是业务研发？ 如果选型的是采购的同学，他们更注重成本，包括存储方式、网络需求等。 如果选型的是 DBA 同学，他们关心的： ① 运维成本 首先是运维成本，包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等； ② 稳定性 其次，DBA会关注稳定性，包括是否支持数据多副本、服务高可用、多写多活等； ③ 性能 第三是性能，包括延迟、QPS 以及是否支持更高级的分级存储功能等； ④ 拓展性 第四是扩展性，如果业务的需求不确定，是否容易横向扩展和纵向扩容； ⑤ 安全 最后是安全，需要符合审计要求，不容易出现 SQL 注入或拖库情况。 ⑥ 其他 除了采购和 DBA之外，后台应用研发的同学同样会关注稳定性、性能、扩展性等问题，同时也非常关注数据库接口是否便于开发，是否便于修改数据库 schema 等问题。 接下来我们来看一下爱奇艺使用的数据库类型： MySQL，互联网业务必备系统； TiDB，爱奇艺的 TiDB 实践会有另外的具体介绍； Redis，KV 数据库，互联网公司标配； Couchbase，这个在爱奇艺用得比较多，但国内互联网公司用得比较少，接下来的部分会详细说明； 其他，比如 MongoDB、图数据库、自研 KV 数据库 HiKV 等； 大数据分析相关系统，比如 Hive、Impala 等等。 可以看到爱奇艺的数据库种类还是很多的，这会造成业务开发的同学可能不太清楚在他的业务场景下应该选用哪种数据库系统。 那么，我们先对这些数据库按照接口（SQL、NoSQL）和面向的业务场景（OLTP、OLAP）这两位维度进行一个简单非严谨的分类。 下图中，左上角是面向 OLTP、支持 SQL 的这样一类系统，例如 MySQL，一般支持事务不同的隔离级别， QPS 要求比较高，延时比较低，主要用于交易信息和关键数据的存储，比如订单、VIP 信息等。 左下角是 NoSQL 数据库，是一类针对特殊场景做优化的系统，schema 一般比较简单，吞吐量较高、延迟较低，一般用作缓存或者 KV 数据库。 整个右侧都是 OLAP 的大数据分析系统，包括 Clickhouse、Impala等，一般支持SQL、不支持事务，扩展性比较好，可以通过加机器增加数据的存储量，响应延迟较长。 还有一类数据库是比较中立的，在数据量比较小的时候性能比较好，在数据量较大或复杂查询的时候性能也不差，一般通过不同的存储引擎和查询引擎来满足不同的业务需求，我们把它叫做 HTAP，TiDB 就是这样一种数据库。 二、iQIYI对数据库的优化与完善 前面我们提到了很多种的数据库，那么接下来就和大家介绍一下在爱奇艺我们是怎么使用这些数据库的。 1、MySQL在爱奇艺的使用 ① MySQL 首先是 MySQL。MySQL 基本使用方式是 master-slave + 半同步，支持每周全备+每日增量备份。我们做了一些基本功能的增强，首先是增强了数据恢复工具 Xtrabackup 的性能。 之前遇到一个情况，我们有一个全量库是 300G 数据，增量库每天 70G 数据，总数据量 700G 左右。我们当时只需要恢复一个表的数据，但该工具不支持单表恢复，且整库恢复需要 5 个小时。 针对这个情况我们具体排查了原因，发现在数据恢复的过程中需要进行多次写盘的 IO 操作并且有很多串行操作，所以我们做了一些优化。例如删减过程中的一些写盘操作，减少落盘并将数据处理并行化，优化后整库恢复耗时减少到 100 分钟，而且可以直接恢复单表数据。 然后是适配 DDL 和 DML 工具到内部系统，gh-ostt 和 oak-online-alter-table 在数据量大的时候会造成 master-slave 延时，所以我们在使用工具的时候也增加了延时上的考虑，实时探测Master-Slave 库之间延时的情况，如果延时较大会暂停工具的使用，恢复到正常水平再继续。 ② MySQL高可用 第二是 MySQL 高可用。Master-slave 加上半同步这种高可用方式不太完善，所以我们参照了 MHA 并进行了改动，采用 master + agent 的方式。Agent 在每一个物理机上部署，可以监控这个物理机上的所有实例的状态，周期性地向 master 发送心跳，Master 会实时监测各个Agent的状态。 如果 MySQL故障，会启动 Binlog 补偿机制，并切换访问域名完成 failover。考虑到数据库跨机房跨地区部署的情况，MHA 的 master 我们也做了高可用设计，众多 master 会通过 raft 组成一个 raft group，类似 TiDB 的 PD 模块。目前 MySQL failover 策略支持三种方式：同机房、同地域跨机房以及跨地域。 ③ MySQL拓展能力 第三是提高MySQL扩展能力，以提供更大容量的数据存储。扩展方式有 SDK，例如开源的 ShardingSphere，在爱奇艺的使用也比较广泛。另外就是 Proxy，开源的就更多了。但是 SDK 和 Proxy 使用的问题是支持的 SQL 语句简单，扩容难度大，依赖较多且运维复杂，所以部分业务已经迁移至 TiDB。 ④ 审计 第四是审计。我们在 MySQL 上做了一个插件获取全量 SQL 操作，后端打到 Kafka，下游再接入包括 Clickhouse 等目标端进行 SQL 统计分析。除此之外还有安全策略，包括主动探索是否有 SQL 注入及是否存在拖库情况等，并触发对应的告警。 MySQL 审计插件最大的问题是如何降低对 MySQL 性能的影响，对此我们进行了一些测试，发现使用 General Log 对性能损耗较大，有 10%~20% 的降低。 于是我们通过接口来获取 MySQL 插件里的监控项，再把监控项放到 buffer 里边，用两级的 RingBuffer 来保证数据的写入不会有锁资源竞争。在这个插件里再启动一个线程，从 RingBuffer 里读取数据并把数据打包写到 FIFO 管道里。 我们在每台 MySQL 的物理机里再启动一个 Agent，从管道里阻塞地读取数据发至 Kafka。优化后我们再次进行压测，在每台机器上有 15 万的更新、删除或插入操作下不会丢失数据，性能损耗一般情况下小于 2%。 目前已经在公司内部的集群上线了一年时间，运行比较稳定，上线和下线对业务没有影响。 ⑤ 分级存储 第五是分级存储。MySQL 里会存一些过程性的数据，即只需要读写最近一段时间存入的数据，过段时间这些数据就不需要了，需要进行定时清理。 分级存储就是在 MySQL 之上又用了其他存储方式，例如 TiDB 或其他 TokuDB，两者之间可以进行数据自动搬迁和自动归档，同时前端通过 SDK + Proxy 来做统一的访问入口。这样一来，业务的开发同学只需要将数据存入 MySQL 里，读取时可能从后端接入的任意数据库读出。这种方式目前只是过渡使用，之后会根据 TiDB 的特性进行逐步迁移。 Redis在爱奇艺的使用 接下来是 Redis。Redis 也是使用 master - slave 这种方式，由于网络的复杂性我们对 Sentinel 的部署进行了一些特殊配置，在多机房的情况下每个机房配置一定数量 Sentinel 来避免脑裂。 备份恢复方面介绍一个我们的特殊场景，虽然 Redis 是一个缓存，但我们发现不少的业务同学会把它当做一个 KVDB 来使用，在某些情况下会造成数据的丢失。 所以我们做了一个 Redis 实时备份功能，启动一个进程伪装成 Redis 的 Slave 实时获取数据，再放到后端的 KV 存储里，例如 ScyllaDB，如果要恢复就可以从 ScyllaDB 里把数据拉出来。 我们在用 Redis 时最大的痛点就是它对网络的延迟或抖动非常敏感。如有抖动造成 Redis Master 超时，会由 Sentinel 重新选出一个新的节点成为 Master，再把该节点上的数据同步到所有 Slave 上，此过程中数据会放在 Master 节点的 Buffer 里，如果写入的 QPS 很高会造成 Buffer 满溢。如果 Buffer 满后 RDB 文件还没有拷贝过去，重建过程就会失败。 基于这种情况，我们对 Redis 告警做了自动化优化，如有大量 master - slave 重建失败，我们会动态调整一些参数，例如把 Buffer 临时调大等， 此外我们还做了 Redis 集群的自动扩缩容功能。 我们在做 Redis 开发时如果是 Java 语言都会用到 Jedis。用 Jedis 访问客户端分片的 Redis 集群，如果某个分片发生了故障或者 failover，Jedis 就会对所有后端的分片重建连接。如果某一分片发生问题，整个 Redis 的访问性能和 QPS 会大幅降低。针对这个情况我们优化了 Jedis，如果某个分片发生故障，就只针对这个分片进行重建。 在业务访问 Redis 时我们会对 Master 绑定一个读写域名，多个从库绑定读域名。但如果我们进行 Master failover，会将读写域名从某旧 Master 解绑，再绑定到新 Master 节点上。 DNS 本身有一个超时时间，所以数据库做完 failover 后业务程序里没有立刻获取到新的 Master 节点的 IP的话，有可能还会连到原来的机器上，造成访问失败。 我们的解决方法是把 DNS 的 TTL 缩短，但对 DNS 服务又会造成很大的压力，所以我们在 SDK 上提供 Redis 的名字服务 RNS，RNS 从 Sentinel 里获取集群的拓扑和拓扑的变化情况，如果集群 failover，Sentinel 会接到通知，客户端就可以通过 RNS 来获取新的 Master 节点的 IP 地址。我们去掉域名，通过 IP 地址来访问整个集群，屏蔽了 DNS 的超时，缩短了故障的恢复时间。 SDK 上还做了一些功能，例如 Load Balance 以及故障检测，比如某个节点延时较高的话会被临时熔断等。 客户端分片的方式会造成 Redis 的扩容非常痛苦，如果客户端已经进行了一定量的分片，之后再增加就会非常艰难。 Redis 在 3.0 版本后会提供 Redis Cluster，因为功能受限在爱奇艺应用的不是很多，例如不支持显示跨 DC 部署和访问，读写只在主库上等。 我们某些业务场景下会使用 Redis 集群，例如数据库访问只发生在本 DC，我们会在 DC 内部进行 Cluster 部署。 但有些业务在使用的过程中还是想做 failover，如果集群故障可以切换到其他集群。根据这种情况我们做了一个 Proxy，读写都通过它来进行。写入数据时 Proxy 会做一个旁路，把新增的数据写在 Kafka 里，后台启用同步程序再把 Kafka 里的数据同步到其他集群，但存在一些限制，比如我们没有做冲突检测，所以集群间数据需要业务的同学做单元化。线上环境的Redis Cluster 集群间场景跨 DC 同步 需要 50 毫秒左右的时间。 2、Couchbase在爱奇艺的使用 Redis 虽然提供 Cluster 这种部署方式，但存在一些问题。所以数据量较大的时候（经验是 160G），就不推荐 Redis 了，而是采用另一种存储方式 Couchbase。 Couchbase 在国内互联网公司用的比较少，一开始我们是把他当做一个 Memcached 来使用的，即纯粹的缓存系统。 但其实它性能还是比较强大的，是一个分布式高性能的 KV 系统，支持多种存储引擎 (bucket)。第一种是 Memcached bucket，使用方式和 Memcached 一样为 KV 存储，不支持数据持久化也没有数据副本，如果节点故障会丢失数据； 第二种是 Couchbase bucket，支持数据持久化，使用 Json 写入，有副本，我们一般会在线上配置两个副本，如果新加节点会对数据进行 rebalance，爱奇艺使用的一般是 Couchbase bucket 这种配置。 Couchbase 数据的分布如下图，数据写入时在客户端上会先进行一次哈希运算，运算完后会定位 Key 在哪一个 vBucket （相当于数据库里的某个分片）。之后客户端会根据 Cluster Map 发送信息至对应的服务端，客户端的 Cluster Map 保存的是 vBucket 和服务器的映射关系，在服务端数据迁移的过程中客户端的 Cluster Map 映射关系会动态更新，因此客户端对于服务端的 failover 操作不需要做特殊处理，但可能在 rebalance 过程中会有短暂的超时，导致的告警对业务影响不大。 Couchbase 在爱奇艺应用比较早，2012 年还没有 Redis Cluster 的时候就开始使用了。集群管理使用 erlang 语言开发，最大功能是进行集群间的复制，提供多种复制方式：单向、双向、星型、环式、链式等。 爱奇艺从最初的 1.8 版本使用到如今的 5.0 版本，正在调研的 6.0，中间也遇到了很多坑，例如 NTP 时间配置出错会导致崩溃，如果每个集群对外 XDCR 并发过高导致不稳定，同步方向变更会导致数据丢失等等，我们通过运维和一些外部工具来进行规避。 Couchbase 的集群是独立集群，集群间的数据同步通过 XDCR，我们一般配置为双向同步。对于业务来说，如果 Cluster 1 写入， Cluster 2 不写入，正常情况下客户端会写 Cluster 1。如果 Cluster 1 有故障，我们提供了一个 Java SDK，可以在配置中心把写入更改到 Cluster 2，把原来到 Cluster 1 的连接逐步断掉再与Cluster 2 新建连接。这种集群 failover 的过程对于客户端来说是相对透明和无感的。 3、爱奇艺自研数据库HiKV的使用 Couchbase 虽然性能非常高，并且数据的存储可以超过内存。但是，如果数据量超过内存 75% 这个阈值，性能就会下降地特别快。在爱奇艺，我们会把数据量控制在可用内存的范围之内，当做内存数据库使用。但是它的成本非常高，所以我们后面又开发了一个新的数据库—— HiKV。 开发 HiKV 的目的是为了把一些对性能要求没那么高的 Couchbase 应用迁移到 HiKV 上。HiKV 基于开源系统 ScyllaDB，主要使用了其分布式数据库的管理功能，增加了单机存储引擎 HiKV。 ScyllaDB 比较吸引人的是它宣称性能高于 Cassandra 十倍，又完全兼容 Cassandra 接口，设计基本一致，可以视为 C++ 版 Cassandra 系统。 ScyllaDB 性能的提升主要是使用了一些新的技术框架，例如 C++ 异步框架 seastar，主要原理是在j每台物理机的核上会 attach 一个应用线程，每个核上有自己独立的内存、网络、IO 资源，核与核之间没有数据共享但可以通信，其最大的好处是内存访问无锁，没有冲突过程。 当一个数据读或写到达 ScyllaDB 的 server 时，会按照哈希算法来判断请求的 Key 是否是该线程需要处理的，如果是则本线程处理，否则会转发到对应线程上去。 除此之外，它还支持多副本、多数据中心、多写多活，功能比较强大。 在爱奇艺，我们基于 SSD 做了一个 KV 存储引擎。Key 放在内存里，Value 放在盘上的文件里，我们在读和写文件时，只需要在内存索引里定位，再进行一次盘的 IO 开销就可以把数据读出来，相比 ScyllaDB 原本基于 LSM Tree 的存储引擎方式对 IO 的开销较少。 索引数据全部放在内存中，如果索引长度较长会限制单机可存储的数据量，于是我们通过开发定长的内存分布器，对于比较长的 Key 做摘要缩短长度至 20 字节，采用红黑树索引，限制每条记录在内存里的索引长度至为 64 字节。内存数据要定期做 checkpoint，客户端要做限流、熔断等。 HiKV 目前在爱奇艺应用范围比较大，截至目前已经替换了 30% 的 Couchbase，有效地降低了存储成本。 4、爱奇艺的数据库运维管理 爱奇艺数据库种类较多，如何高效地运维和管理这些数据库也是经历了不同的阶段。 最初我们通过 DBA 写脚本的方式管理，如果脚本出问题就找 DBA，导致了 DBA 特别忙碌。 第二个阶段我们考虑让大家自己去查问题的答案，于是在内部构建了一个私有云，通过 Web 的方式展示数据库运行状态，让业务的同学可以自己去申请集群，一些简单的操作也可以通过自服务平台实现，解放了 DBA。一些需要人工处理的大型运维操作经常会造成一些人为故障，敲错参数造成数据丢失等。 于是在第三个阶段我们把运维操作 Web 化，通过网页点击可以进行 90% 的操作。 第四个阶段让经验丰富的 DBA 把自身经验变成一些工具，比如有业务同学说 MySQL master-slave 延时了，DBA 会通过一系列操作排查问题。现在我们把这些操作串起来形成一套工具，出问题时业务的同学可以自己通过网页上的一键诊断工具去排查，自助进行处理。 除此之外我们还会定期做预警检查，对业务集群里潜在的问题进行预警报告；开发智能客服，回答问题；通过监控的数据对实例打标签，进行削峰填谷地智能调度，提高资源利用率。 三、不同场景下数据库选型建议 1、实用数据库选型树 最后来说一些具体数据库选型建议。这是 DBA 和业务一起，通过经验得出来的一些结论。 对于关系型数据库的选型来说，可以从数据量和扩展性两个维度考虑，再根据数据库有没有冷备、要不要使用 Toku 存储引擎，要不要使用 Proxy 等等进行抉择。 NoSQL 也是什么情况下使用 master-slave，什么情况下使用客户端分片、集群、Couchbase、HiKV 等，我们内部自服务平台上都有这个选型树信息。 2、一些思考 ① 需求 我们在选型时先思考需求，判断需求是否真实。 你可以从数据量、QPS、延时等方面考虑需求，但这些都是真实需求吗？是否可以通过其他方式把这个需求消耗掉，例如在数据量大的情况下可以先做数据编码或者压缩，数据量可能就降下来了。 不要把所有需求都推到数据库层面，它其实是一个兜底的系统。 ② 选择 第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么？是因为热门吗？还是因为技术上比较先进？但是不是能真正地解决你的问题？如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。 ③ 放弃 第三是放弃，当你放弃一个系统时真的是因为不好用吗？还是没有用好？放弃一个东西很难，但在放弃时最好有一个充分的理由，包括实测的结果。 ④ 自研 第四是自研，在需要自己开发数据库时可以参考和使用一些成熟的产品，但不要盲目自研。 ⑤ 开源 最后是开源，要有拥抱开源的态度。