基础算法如何搭建

成为一名合格的开发工程师不是一件简单的事情，需要掌握从开发到调试到优化等一系列能力，这些能力中的每一项掌握起来都需要足够的努力和经验。而要成为一名合格的机器学习算法工程师（以下简称算法工程师）更是难上加难，因为在掌握工程师的通用技能以外，还需要掌握一张不算小的机器学习算法知识网络。 下面我们就将成为一名合格的算法工程师所需的技能进行拆分，一起来看一下究竟需要掌握哪些技能才能算是一名合格的算法工程师。 1.基础开发能力 所谓算法工程师，首先需要是一名工程师，那么就要掌握所有开发工程师都需要掌握的一些能力。 有些同学对于这一点存在一些误解，认为所谓算法工程师就只需要思考和设计算法，不用在乎这些算法如何实现，而且会有人帮你来实现你想出来的算法方案。这种思想是错误的，在大多数企业的大多数职位中，算法工程师需要负责从算法设计到算法实现再到算法上线这一个全流程的工作。 笔者曾经见过一些企业实行过算法设计与算法实现相分离的组织架构，但是在这种架构下，说不清楚谁该为算法效果负责，算法设计者和算法开发者都有一肚子的苦水，具体原因不在本文的讨论范畴中，但希望大家记住的是，基础的开发技能是所有算法工程师都需要掌握的。 2.概率和统计基础 概率和统计可以说是机器学习领域的基石之一，从某个角度来看，机器学习可以看做是建立在概率思维之上的一种对不确定世界的系统性思考和认知方式。学会用概率的视角看待问题，用概率的语言描述问题，是深入理解和熟练运用机器学习技术的最重要基础之一。 概率论内容很多，但都是以具体的一个个分布为具体表现载体体现出来的，所以学好常用的概率分布及其各种性质对于学好概率非常重要。 对于离散数据，伯努利分布、二项分布、多项分布、Beta分布、狄里克莱分布以及泊松分布都是需要理解掌握的内容； 对于离线数据，高斯分布和指数分布族是比较重要的分布。这些分布贯穿着机器学习的各种模型之中，也存在于互联网和真实世界的各种数据之中，理解了数据的分布，才能知道该对它们做什么样的处理。 此外，假设检验的相关理论也需要掌握。在这个所谓的大数据时代，最能骗人的大概就是数据了，掌握了假设检验和置信区间等相关理论，才能具备分辨数据结论真伪的能力。例如两组数据是否真的存在差异，上线一个策略之后指标是否真的有提升等等。这种问题在实际工作中非常常见，不掌握相关能力的话相当于就是大数据时代的睁眼瞎。 在统计方面，一些常用的参数估计方法也需要掌握，典型的如最大似然估计、最大后验估计、EM算法等。这些理论和最优化理论一样，都是可以应用于所有模型的理论，是基础中的基础。 3.机器学习理论 虽然现在开箱即用的开源工具包越来越多，但并不意味着算法工程师就可以忽略机器学习基础理论的学习和掌握。这样做主要有两方面的意义： 掌握理论才能对各种工具、技巧灵活应用，而不是只会照搬套用。只有在这个基础上才能够真正具备搭建一套机器学习系统的能力，并对其进行持续优化。否则只能算是机器学习搬砖工人，算不得合格的工程师。出了问题也不会解决，更谈不上对系统做优化。 学习机器学习的基础理论的目的不仅仅是学会如何构建机器学习系统，更重要的是，这些基础理论里面体现的是一套思想和思维模式，其内涵包括概率性思维、矩阵化思维、最优化思维等多个子领域，这一套思维模式对于在当今这个大数据时代做数据的处理、分析和建模是非常有帮助的。如果你脑子里没有这套思维，面对大数据环境还在用老一套非概率的、标量式的思维去思考问题，那么思考的效率和深度都会非常受限。 机器学习的理论内涵和外延非常之广，绝非一篇文章可以穷尽，所以在这里我列举了一些比较核心，同时对于实际工作比较有帮助的内容进行介绍，大家可在掌握了这些基础内容之后，再不断探索学习。 4.开发语言和开发工具 掌握了足够的理论知识，还需要足够的工具来将这些理论落地，这部分我们介绍一些常用的语言和工具。 5.架构设计 最后我们花一些篇幅来谈一下机器学习系统的架构设计。 所谓机器学习系统的架构，指的是一套能够支持机器学习训练、预测、服务稳定高效运行的整体系统以及他们之间的关系。 在业务规模和复杂度发展到一定程度的时候，机器学习一定会走向系统化、平台化这个方向。这个时候就需要根据业务特点以及机器学习本身的特点来设计一套整体架构，这里面包括上游数据仓库和数据流的架构设计，以及模型训练的架构，还有线上服务的架构等等。这一套架构的学习就不像前面的内容那么简单了，没有太多现成教材可以学习，更多的是在大量实践的基础上进行抽象总结，对当前系统不断进行演化和改进。但这无疑是算法工程师职业道路上最值得为之奋斗的工作。在这里能给的建议就是多实践，多总结，多抽象，多迭代。 6.机器学习算法工程师领域现状 现在可以说是机器学习算法工程师最好的时代，各行各业对这类人才的需求都非常旺盛。典型的包括以下一些细分行业： 推荐系统。推荐系统解决的是海量数据场景下信息高效匹配分发的问题，在这个过程中，无论是候选集召回，还是结果排序，以及用户画像等等方面，机器学习都起着重要的作用。 广告系统。广告系统和推荐系统有很多类似的地方，但也有着很显著的差异，需要在考虑平台和用户之外同时考虑广告主的利益，两方变成了三方，使得一些问题变复杂了很多。它在对机器学习的利用方面也和推荐类似。 搜索系统。搜索系统的很多基础建设和上层排序方面都大量使用了机器学习技术，而且在很多网站和App中，搜索都是非常重要的流量入口，机器学习对搜索系统的优化会直接影响到整个网站的效率。 风控系统。风控，尤其是互联网金融风控是近年来兴起的机器学习的又一重要战场。不夸张地说，运用机器学习的能力可以很大程度上决定一家互联网金融企业的风控能力，而风控能力本身又是这些企业业务保障的核心竞争力，这其中的关系大家可以感受一下。 但是所谓“工资越高，责任越大”，企业对于算法工程师的要求也在逐渐提高。整体来说，一名高级别的算法工程师应该能够处理“数据获取数据分析模型训练调优模型上线”这一完整流程，并对流程中的各种环节做不断优化。一名工程师入门时可能会从上面流程中的某一个环节做起，不断扩大自己的能力范围。 除了上面列出的领域以外，还有很多传统行业也在不断挖掘机器学习解决传统问题的能力，行业的未来可谓潜力巨大。

1.产品2.UI3.CSS4.JS5.后端（Java/php/python）6.DBA(mysql/oracle)7.运维（OP） 8.测试（QA）9.算法（分类/聚类/关系抽取/实体识别）10.搜索（Lucene/Solr/elasticSearch）11.大数据工程师（Hadoop）12.Android13.IOS14.运营 一.产品1 工作内容：了解用户需求，做竞品调研，画产品原型，写产品文档，讲解产品需求，测试产品Bug，收集用户反馈，苦练金刚罩以防止程序员拿刀砍。2 需要技能：PPT，Word, Axure,XP,MVP，行业知识，沟通。 二. UI1 工作内容：收到产品原型，给原型上色，偶尔会自作主张调整下原型的位置，出不同的风格给老板和客户选，然后听他们的意见给出一个自己极不喜欢的风格，最好给Android，IOS或者是CSS做好标注，还有的需要直接帮他们切好图，最后要练出来象素眼，看看这些不靠谱的程序员们有没有上错色或者是有偏差。2 需要技能：PS，Illustrator，Sketch，耐性，找素材。 三. CSS1 工作内容：产品设计好原型，UI做出来了效果图，剩下的就是CSS工程师用代码把静态文件写出来的。 2 需要技能：环境【IDE（WEBStorm，Sublime，EditPlus），源码管理（SVN/Git） ，WEB服务器(nginx)】基础【PS，域名，Html，Html5，CSS，CSS3】扩展【自适应，响应式，Bootstrap，Less，Flex】 四 .JS 1 工作内容：JS工程师其实分成两类，在之前讲CSS的时候已经提到过，一个是套页面的，一个是前后端分离的。对这两个概念还是分不太清的，可以回过头去看CSS的部分。 2 需要技能：环境【IDE（WEBStorm，Sublime，EditPlus），源码管理（SVN/Git） ，WEB服务器(nginx)】基础【Http，REST，跨域，语法，组件，F12，Json，Websocket】框架【JQuery，AngularJS，Bower，RequireJS，GruntJS，ReactJS，PhoneGap】业务【金融，教育，医疗，汽车，房产等等等等各种行业】 五 .后端（Java/python/go） 1 工作内容：大部分的后端工程师都停留在功能实现的层面上。这是现在国内二流或者是三流的公司的现状，甚至是在某些一流的公司。很多时候都是架构师出了架构设计，更多的外包公司根本就是有DBA来做设计，然后后端程序员从JS到CSS到Java全写，完全就是一个通道，所有的复杂逻辑全部交给DB来做，这也是几年前DBA很受重视的原因。 2 需要技能：环境【IDE（Idea/Eclipse，Maven，jenkins,Nexus,Jetty,Shell，Host），源码管理（SVN/Git） ，WEB服务器(nginx,tomcat,Resin)】基础【Http，REST，跨域，语法，Websocket,数据库，计算机网络，操作系统，算法，数据结构】框架【Spring，AOP，Quartz，Json TagLib,tiles,activeMQ,memcache,redis,mybatis,log4j,junit等等等等等】业务【金融，教育，医疗，汽车，房产等等等等各种行业】。 六 .DBA  1 工作内容：如果你做了一个DBA，基本上会遇到两种情况。一种是你的后端工程师懂架构，知道怎么合便使用DB，知道如何防止穿透DB，那么恭喜你，你只是需要当一个DB技术兜底的顾问就好，基本上没什么活可以做，做个监控，写个统计就好了。你可以花时间在MongoDB了，Hadoop了这些，随便玩玩儿。再按照我之前说的，做好数据备份。如果需求变动比较大，往往会牵涉到一些线上数据的更改，那么就在发布的时候安静的等着，等着他们出问题。。。。如果不出问题就可以回家睡觉了。 2 需要技能：环境【Linux，Mysql，Oracle，MongoDB，Hadoop】工具【各种DB的版本，工具，备份，日志等】。 七. 运维  1 工作内容：运维的工作大概分成几个部分，我对于修真院学习运维的少年们都这么说，大概是：A。基础环境的搭建和常用软件的安装和配置（兼网管的还有各种程控机）,常用软件指的是SVN，Git，邮箱这种，更细节的内容请参考修真院对于运维职业的介绍。B。日常的发布和维护，如刚刚讲到的一样，测试环境和线上环境的发布和记录，原则上，对线上所有的变更都应该有记录。C。数据的备份和服务的监控&安全配置。各种数据，都要做好备份和回滚的手段，提前准备好各种紧急预案，服务的监制要做好。安全始终都是不怎么被重点考虑的问题，因为这个东西无底洞，你永远不知道做到什么程度算是比较安全了，所以大多数都是看着情况来。D。运维工具的编写。这一点在大的云服务器商里格外常见，大公司也是一样的。E。Hadoop相关的大数据体系架构的运维，确实有公司在用几百台机器做Hadoop，所以虽然不常见，我还是列出来吧。 2 需要技能：环境【Linux，Mysql，Oracle，MongoDB，Hadoop，nginx,apache,F5,lvs,vpn,iptable，svn,git,memcache,redis】工具【linux 常用工具，Mysql常用工具，Jenkins，zabbix,nagios】自动化运维【openstack,docker,ansible】语言【shell,python】 八 .QA  1 工作内容：QA需要了解需求，很多公司会要求QA写测试用例，我觉得是扯淡。完全是在浪费时间。通常开发三周，QA测试的时间只有一周到一周半。还有关于提前写测试用例的，都不靠谱。 2 需要技能：流程【Bug修复流程，版本发布流程】工具【禅道，BugZilla，Jira,Excel表格来统计Bug数，自动化测试】性格【严谨，耐心】 九. 算法工程师  1 工作内容：算法工程师的工作内容，大部分时间都是在调优。就是调各种参数和语料，寻找特征，验证结果，排除噪音。也会和Hadoop神马的打一些交道，mahout神马的，我那个时候还在用JavaML。现在并不知道有没有什么更好用的工具了。有的时候还要自己去标注语料---当然大部分人都不爱做这个事儿，会找漂亮的小编辑去做。2 需要技能：基础【机器学习，数据挖掘】工具【Mahout，JavaML等其他的算法工具集】 十. 搜索工程师  1 工作内容： 所以搜索现在其实分成两种。一种是传统的搜索。包括：A。抓取 B。解析C。去重D。处理E。索引F。查询另一种是做为架构的搜索。并不包括之前的抓取解析去重，只有索引和查询。A。索引B。查询 2 需要技能：环境【Linux】框架【Luence,Slor,ElasticSearch,Cassandra,MongoDB】算法【倒排索引，权重计算公式，去重算法，Facet搜索的原理，高亮算法，实时索引】 十一. 大数据工程师  1 工作内容：工作内容在前期会比较多一些，基础搭建还是一个挺讲究的事儿。系统搭建好之后呢，大概是两种，一种是向大数据部门提交任务，跑一圈给你。一种是持续的文本信息处理中增加新的处理模块，像我之前说的增加个分类啦，实体识别神马的。好吧第一种其实我也不记得是从哪得来的印象了，我是没有见到过的。架构稳定了之后，大数据部门的工作并不太多，常常会和算法工程师混到一起来。其他的应该就是大数据周边产品的开发工作了。再去解决一些Bug什么的。2 需要技能：环境【Linux】框架【Hadoo,spark,storm,pig,hive,mahout,zookeeper 】算法【mapreduce,hdfs,zookeeper】。 十二. Android工程师  1 工作内容：Android工程师的日常就是听产品经理讲需求，跟后端定接口，听QA反馈哪款机器不兼容，闹着申请各种测试机，以及悲催的用Android做IOS的控件。 2 需要技能：环境【Android Studio，Maven,Gradle】基础【数据结构，Java，计算机网络】组件【IM，地图，支付，拍照，视频，音频，统计，分享，手势密码】 十三. IOS工程师  1 工作内容：IOS工程师的工作内容真的挺简单的，听需求，定接口。做个适配，抛弃一下iphone4。还有啥。。马丹，以我为数不多的IOS知识来讲，真的不知道还有啥了。我知道的比较复杂的系统也是各种背景高斯模糊，各种渐变，各种图片滤镜处理，其他并没有什么。支付，地图，统计这些东西。 嗯。2 需要技能：环境【Xcode】基础【数据结构，Object，计算机网络】组件【IM，地图，支付，拍照，视频，音频，统计，分享，手势密码】

您好，架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物，架构师就是确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。从Java技术栈发展成为架构师：（1）熟练使用各种框架，并知道它们实现的原理。（2）jvm虚拟机原理、调优，懂得jvm能让你写出性能更好的代码；池技术，什么对象池，连接池，线程池……Java反射技术，写框架必备的技术，遇到有严重的性能问题，替代方案java字节码技术；nio，没什么好说的，值得注意的是"直接内存"的特点，使用场景；java多线程同步异步；java各种集合对象的实现原理，了解这些可以让你在解决问题时选择合适的数据结构，高效的解决问题。总之一句话，越基础的东西越重要，很多人认为自己会用它们写代码了，其实仅仅是知道如何调用api而已，离会用还差的远。如果你立志做架构，首先打好基础，从最底层开始。而Java学到极致势必涉及到设计模式，算法和数据结构，多线程，文件及网络IO，数据库及ORM，不一而足。这些概念放之一切语言都适用。

大数据平台的搭建步骤： 1、linux系统安装    一般使用开源版的Redhat系统--CentOS作为底层平台。为了提供稳定的硬件基础，在给硬盘做RAID和挂载数据存储节点的时，需要按情况配置。2、分布式计算平台/组件安装  国内外的分布式系统的大多使用的是Hadoop系列开源系统。Hadoop的核心是HDFS，一个分布式的文件系统。在其基础上常用的组件有Yarn、Zookeeper、Hive、Hbase、Sqoop、Impala、ElasticSearch、Spark等使用开源组件的优点：1）使用者众多，很多bug可以在网上找的答案（这往往是开发中最耗时的地方）。2）开源组件一般免费，学习和维护相对方便。3）开源组件一般会持续更新，提供必要的更新服务『当然还需要手动做更新操作』。4）因为代码开源，若出bug可自由对源码作修改维护。3、数据导入数据导入的工具是Sqoop。用它可以将数据从文件或者传统数据库导入到分布式平台『一般主要导入到Hive，也可将数据导入到Hbase』。4、数据分析数据分析一般包括两个阶段：数据预处理和数据建模分析。数据预处理是为后面的建模分析做准备，主要工作时从海量数据中提取可用特征，建立大宽表。这个过程可能会用到Hive SQL，Spark QL和Impala。数据建模分析是针对预处理提取的特征/数据建模，得到想要的结果。这一块最好用的是Spark。常用的机器学习算法，如朴素贝叶斯、逻辑回归、决策树、神经网络、TFIDF、协同过滤等，都已经在ML lib里面，调用比较方便。5、结果可视化及输出API可视化一般式对结果或部分原始数据做展示。一般有两种情况，行数据展示，和列查找展示。要基于大数据平台做展示，会需要用到ElasticSearch和Hbase。Hbase提供快速『ms级别』的行查找。 ElasticSearch可以实现列索引，提供快速列查找。 大数据平台搭建中的主要问题1、稳定性 Stability 理论上来说，稳定性是分布式系统最大的优势，因为它可以通过多台机器做数据及程序运行备份以确保系统稳定。但也由于大数据平台部署于多台机器上，配置不合适，也可能成为最大的问题。 2、可扩展性 Scalability 如何快速扩展已有大数据平台，在其基础上扩充新的机器是云计算等领域应用的关键问题。在实际2B的应用中，有时需要增减机器来满足新的需求。如何在保留原有功能的情况下，快速扩充平台是实际应用中的常见问题。 来源于网络，供您参考,如若满意，请点击右侧【采纳答案】，如若还有问题，请点击【追问】 希望我的回答对您有所帮助，望采纳！ ~ O(∩_∩)O~

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

1，架构师是什么？要想往架构师的方向发展首先要知道架构师是什么？架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。一个架构师得需要足够的想像力,能把各种目标需求进行不同维度的扩展，为目标客户提供更为全面的需求清单。架构师在软件开发的整个过程中起着很重要的作用。说的详细一些，架构师就是确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。主要着眼于系统的“技术实现”。2，架构师的任务架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。他必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个架构师工作的好坏决定了整个软件开发项目的成败。在成为Java架构师之前，应当先成为Java工程师。熟练使用各种框架，并知道它们实现的原理。jvm虚拟机原理、调优，懂得jvm能让你写出性能更好的代码；池技术，什么对象池，连接池，线程池……Java反射技术，写框架必备的技术，遇到有严重的性能问题，替代方案java字节码技术；nio，没什么好说的，值得注意的是"直接内存"的特点，使用场景；java多线程同步异步；java各种集合对象的实现原理，了解这些可以让你在解决问题时选择合适的数据结构，高效的解决问题，比如hashmap的实现原理，好多五年以上经验的人都弄不清楚，还有为什扩容时有性能问题？不弄清楚这些原理，就写不出高效的代码，还会认为自己做的很对；总之一句话，越基础的东西越重要，很多人认为自己会用它们写代码了，其实仅仅是知道如何调用api而已,离会用还差的远。如果你立志做架构，首先打好基础，从最底层开始。然后发展到各种技术和语言，什么都要懂两点，要全面且不肤浅。为什么不是懂一点？你要看得透彻，必须尽量深入一些。别人懂一点，你要做架构师，必须再多懂一点。比如你发现golang很流行，别人可能写一个helloworld就说自己玩过golang，但你至少要尝试写一个完整的应用。不肯下苦功，如何高人一头？另外你要非常深入地了解至少一门语言，如果你的目标是java，就学到极致，作为敲门砖，先吃饱了才能谈理想。3，架构师都是从码农过来的而Java学到极致势必涉及到设计模式，算法和数据结构，多线程，文件及网络IO，数据库及ORM，不一而足。这些概念放之一切语言都适用。先精一门，为全面且不肤浅打基础。另外就是向有经验的架构师学习，和小伙伴们讨论辩论争论。其实最重要的能力就是不断学习。在思考新的技术是否能更好地解决你们遇到的问题之前，你首先得知道并了解新的技术。架构师都是从码农过来的，媳妇熬成婆。千万不要成为不写代码的架构师，有些公司专门产不写技术的架构师。所谓架构师，只是功底深厚的程序员而已。个人认为应该扎扎实实学习基础知识，学习各种规范，架构，需要广泛的知识面，懂的东西越多视野越开阔，设计的东西当然会越好越全面。成为架构师需要时间的积累的，不但要知其然还要知其所以然。平时的一点一滴你感觉不到特别用处，但某天你会发现所有东西都没有白学的。4，架构师知识体系下面是我总结多年经验开发的架构师知识体系一、分布式架构架构分布式的英文（ Distributed computing 分布式计算技术）的应用和工具，成熟目前的技术包括 J2EE，CORBA 和 .NET（DCOM），这些技术牵扯的内容非常广，相关的书籍也非常多。本文不介绍这些技术的内容，也没有涉及这些技术的细节，只是从各种分布式系统平台产生的背景和在软件开发中应用的情况来探讨它们的主要异同。分布式系统是一个古老而宽泛的话题，而近几年因为“大数据”概念的兴起，又焕发出了新的青春与活力。除此之外，分布式系统也是一门理论模型与工程技法。并重的学科内容相比于机器学习这样的研究方向，学习分布式系统的同学往往会感觉：“入门容易，深入难”的确，学习分布式系统几乎不需要太多数学知识。分布式系统是一个复杂且宽泛的研究领域，学习一两门在线课程，看一两本书可能都是不能完全覆盖其所有内容的。总的来说，分布式系统要做的任务就是把多台机器有机的组合，连接起来，让其协同完成一件任务，可以是计算任务，也可以是存储任务。如果一定要给近些年的分布式系统研究做一个分类的话，我个人认为大概可以包括三大部分：分布式存储系统分布式计算系统分布式管理系统二、微服务当前微服务很热，大家都号称在使用微服务架构，但究竟什么是微服务架构？微服务架构是不是发展趋势？对于这些问题，我们都缺乏清楚的认识。为解决单体架构下的各种问题，微服务架构应运而生。与其构建一个臃肿庞大，难以驯服的怪兽，还不如及早将服务拆分。微服务的核心思想便是服务拆分与解耦，降低复杂性。微服务强调将功能合理拆解，尽可能保证每个服务的功能单一，按照单一责任原则（Single Responsibility Principle）明确角色。将各个服务做轻，从而做到灵活，可复用，亦可根据各个服务自身资源需求，单独布署，单独作横向扩展。微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多 SOLID 原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发，管理和迭代在分散的组件中使用云架构和平台式部署，管理和服务功能，使产品交付变得更加简单。本质：用一些功能比较明确，业务比较精练的服务去解决更大，更实际的问题。三、源码分析从字面意义上来讲，源文件的英文指一个文件，指源代码的集合。源代码则是一组具有特定意义的可以实现特定功能的字符（程序开发代码）。源码分析是一种临界知识，掌握了这种临界知识，能不变应万变，源码分析对于很多人来说很枯燥，生涩难懂。源码阅读，我觉得最核心有三点：技术基础+强烈的求知欲+耐心。我认为是阅读源码的最核心驱动力我见到绝大多数程序员，对学习的态度，基本上就是这几个层次（很偏激哦）：1，只关注项目本身，不懂就百度一下。2，除了做好项目，还会阅读和项目有关的技术书籍，看维基百科。3，除了阅读和项目相关的书外，还会阅读IT行业的书，比如学的Java的时，还会去了解函数语言，如LISP。4，找一些开源项目看看，大量试用第三方框架，还会写写演示。5，阅读基础框架，J2EE 规范，调试服务器内核。大多数程序都是第1种，到第5种不光需要浓厚的兴趣，还需要勇气：？我能读懂吗其实，你能够读懂的耐心，真的很重要。因为你极少看到阅读源码的指导性文章或书籍，也没有人要求或建议你读。你读的过程中经常会卡住，而一卡主可能就陷进了迷宫这时，你需要做的，可能是暂时中断一下，再从外围看看它：如API结构，框架的设计图。四、工具使用工欲善其事必先利其器，工具对 Java 的的程序员的重要性不言而喻现在有很多库，实用工具和程序任的 Java 的开发人员选择。下图列出的工具都是程序员必不可少的工具五、性能优化不管是应付前端面试还是改进产品体验，性能优化都是躲不开的话题。优化的目的是让用户有“快”的感受，那如何让用户感受到快呢？加载速度真的很快，用户打开输入网址按下回车立即看到了页面加载速度并没有变快，但用户感觉你的网站很快性能优化取决于多个因素，包括垃圾收集，虚拟机和底层操作系统（OS）设置。有多个工具可供开发人员进行分析和优化时使用，你可以通过阅读爪哇工具的源代码优化和分析来学习和使用它们。必须要明白的是，没有两个应用程序可以使用相同的优化方式，也没有完美的优化的 Java 应用程序的参考路径。使用最佳实践并且坚持采用适当的方式处理性能优化。想要达到真正最高的性能优化，你作为一个 Java 的开发人员，需要对 Java 的虚拟机（JVM）和底层操作系统有正确的理解。性能优化，简而言之，就是在不影响系统运行正确性的前提下，使之运行地更快，完成特定功能所需的时间更短。性能问题永远是永恒的主题之一，而优化则更需要技巧。Java程序员如何学习才能快速入门并精通呢？当真正开始学习的时候难免不知道从哪入手，导致效率低下影响继续学习的信心。但最重要的是不知道哪些技术需要重点掌握，学习时频繁踩坑，最终浪费大量时间，所以有一套实用的视频课程用来跟着学习是非常有必要的。为了让学习变得轻松、高效，今天给大家免费分享一套阿里架构师传授的一套教学资源。帮助大家在成为架构师的道路上披荆斩棘。这套视频课程详细讲解了（Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构）等这些成为架构师必备的内容！而且还把框架需要用到的各种程序进行了打包，根据基础视频可以让你轻松搭建分布式框架环境，像在企业生产环境一样进行学习和实践。

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

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

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工具包，操作简单，但是每次需要重新部署。 用