数据查询系统可以做什么

用mysql自带函数有什么不好？1.很可能造成where后的条件无法走索引2.把一些php层面简单的业务逻辑交给mysql来做，加大了mysql的压力（尽管可能你看来执行一次sql语句影响很小），对小系统而言没什么。如果对于大型系统，那会是灾难。大型系统的瓶颈基本都在数据库层面难以扩展，php很容易的水平扩展，php不会是瓶颈，因此，尽可能的降低数据库的处理压力，包括减少查询次数通过cache来解决，减少每次查询的时间则通过索引以及尽可能的业务在php层面处理，mysql只做最基本简单的查询少使用自带函数。那mysql自带函数为什么存在？比如一些数据初始化是可以用，或者存储过程等..小型系统可以使用mysql自带函数，反正没啥瓶颈不能因为大型系统不建议查询用自带函数就不提供，因为考虑到普遍的需求比如php框架的ORM设计，很费资源又慢，大型系统也不建议用，小系统就随便用，方便又快速。总结就是不能因为一些场景不建议用就不提供...方便快速的代价就是性能。

我觉得有三个维度，第一是说人工智能AI的技术来智能化的管控平台。我们现在数据库实例非常多，系统处理也变得越来越复杂。像NoSQL、OLTP、OLAP，要处理结构化数据，同时也要处理非结构化数据等等。在阿里，管理云上超过了几十万的实例数，集团内也有几十万的实例数，如何去高效和管理这么多的数据库实例？异常发现、异常检测、Slow SQL、MySQL、内存管理等这些都是依赖人工智能技术的。比如说在阿里巴巴集团内部用机器学习和人工智能技术实时去采集所有实例运行的状态，把它的IO/CPO的使用率和它的Workload的特点，去在线建模做8份大小的调整，每一个数据库的实例它是4G、8G、16G。为什么要做这件事？因为随着它一天Workload的变化，它实际上不需要在一天内的任何时候都需要一个非常大的Buffer，可能高峰Buffer要扩，等到峰值过去后Buffer可以缩下来，这样的话就可以把内存资源做一个动态调度。 第二是在内核里面。比如说做内存管理和做查询优化，现在业界也在开始使用一些机器学习的方法。传统使用一些简单的统计方法来做一些内存管理、做查询优化、Buffer Management，比如说LRU 或者 MRU这种非常简单的方式。现在可以看到有一些人工智能和机器学习的方法来做更复杂但是更智能化的、高效的智能化管理，以及CBO这是查询优化里很重要的一块。 第三个维度是说在数据库的应用层，需要对非结构化的数据进行处理，除了结构化的数据。比如说在ADB里面就把非结构化数据先做一个转换，把它从非结构化数据转化到高纬的向量，比如说用 embeddng把这种文档或者是图像甚至像视频都可以把他们映射到一个高维的空间里面，这样的话做一个向量处理引擎，就能把这种非结构化数据变成高维向量，再通过这些高维向量处理引擎把这些非结构化数据和结构化数据在一个数据库引擎里进行联合的查询和分析。这就是用数据库系统来支持AI机器学习和数据处理和 Workload。 总结来讲有两个维度AI或DB，就是机器学习和人工智能技术使得数据库系统更高效、更可靠、更好用。另外一个是DB或AI，就是用数据库的系统来支持机器学习和人工智能的处理。

首先是 DNS 查询，如果这一步做了智能 DNS 解析的话，会提供访问速度最快的 IP 地址回来。 DNS DNS 的作用就是通过域名查询到具体的 IP。 因为 IP 存在数字和英文的组合（IPv6），很不利于人类记忆，所以就出现了域名。你可以把域名看成是某个 IP 的别名，DNS 就是去查询这个别名的真正名称是什么。 在 TCP 握手之前就已经进行了 DNS 查询，这个查询是操作系统自己做的。当你在浏览器中想访问 www.google.com 时，会进行一下操作： 操作系统会首先在本地缓存中查询 IP没有的话会去系统配置的 DNS 服务器中查询如果这时候还没得话，会直接去 DNS 根服务器查询，这一步查询会找出负责 com 这个一级域名的服务器然后去该服务器查询 google 这个二级域名接下来三级域名的查询其实是我们配置的，你可以给 www 这个域名配置一个 IP，然后还可以给别的三级域名配置一个 IP 以上介绍的是 DNS 迭代查询，还有种是递归查询，区别就是前者是由客户端去做请求，后者是由系统配置的 DNS 服务器做请求，得到结果后将数据返回给客户端。 PS：DNS 是基于 UDP 做的查询，大家也可以考虑下为什么之前不考虑使用 TCP 去实现。 接下来是 TCP 握手，应用层会下发数据给传输层，这里 TCP 协议会指明两端的端口号，然后下发给网络层。网络层中的 IP 协议会确定 IP 地址，并且指示了数据传输中如何跳转路由器。然后包会再被封装到数据链路层的数据帧结构中，最后就是物理层面的传输了。 在这一部分中，可以详细说下 TCP 的握手情况以及 TCP 的一些特性。 当 TCP 握手结束后就会进行 TLS 握手，然后就开始正式的传输数据。 在这一部分中，可以详细说下 TLS 的握手情况以及两种加密方式的内容。 数据在进入服务端之前，可能还会先经过负责负载均衡的服务器，它的作用就是将请求合理的分发到多台服务器上，这时假设服务端会响应一个 HTML 文件。 首先浏览器会判断状态码是什么，如果是 200 那就继续解析，如果 400 或 500 的话就会报错，如果 300 的话会进行重定向，这里会有个重定向计数器，避免过多次的重定向，超过次数也会报错。 浏览器开始解析文件，如果是 gzip 格式的话会先解压一下，然后通过文件的编码格式知道该如何去解码文件。 文件解码成功后会正式开始渲染流程，先会根据 HTML 构建 DOM 树，有 CSS 的话会去构建 CSSOM 树。如果遇到 script 标签的话，会判断是否存在 async 或者 defer ，前者会并行进行下载并执行 JS，后者会先下载文件，然后等待 HTML 解析完成后顺序执行。 如果以上都没有，就会阻塞住渲染流程直到 JS 执行完毕。遇到文件下载的会去下载文件，这里如果使用 HTTP/2 协议的话会极大的提高多图的下载效率。 CSSOM 树和 DOM 树构建完成后会开始生成 Render 树，这一步就是确定页面元素的布局、样式等等诸多方面的东西 在生成 Render 树的过程中，浏览器就开始调用 GPU 绘制，合成图层，将内容显示在屏幕上了。

我觉得有两个层面：业务层面和系统层面。业务层面我不是很好回答，因为这个业务层面肯定是跟你的业务逻辑有关系的，比如说财务系统和工作流系统，这两个数据要怎么打通？数据打通之后要支持什么样的应用？这些一定是跟你的企业的业务逻辑有强相关性的，它不是一个跟业务逻辑解耦的一件事。所以我没有办法直接说明这个在业务层面怎么操作。 但在系统层面，不根据业务逻辑，一个统一的平台一个接口层可以把一个多元异构的数据。比如说财务系统和工作流系统，甚至可以将两个底层的数据库系统都不一样，财务系统可能用的是一个OLTP的数据库MySQL或者PG，但在工作流系统用的是MongoDB一样的东西，这里面有个解决方案是说可以考虑用数据湖的概念把他们打通，也是我们的一个核心产品，也是业界现在比较火的技术。可以把传统的数据仓库像ADB它是一个云原生的数据仓库和数据湖的概念叠加在一起，可以支持多元异构的建仓然后去做查询和分析。向我们是把ADB和DLA结合起来，像的云原生数据库和云原生数据湖两者结合起来，完美的解决这个问题。DLA可以支持多元异构的数据支持和数据访问，它的特点是数据就可以待在原来的地方，这个是可以考虑的一个方向。

[健] 一个系统最基本的功能就是  登录权限 但是往往别人觉得没技术含量 其实里面学问挺大 可以贴出来一起探讨下 比如数据权限 菜单权限 登录和验证方式啥的 [犀利豆] 好巧，我之前也做个一个，我主要介绍的是技术上的一些点 「如何利用 Spring Hibernate 高级特性设计实现一个权限系统」**[元清] 树描述组织结构少不了，但是我觉得用rbac 思想指导更好[犀利豆] 主要是业务有一些要求，要根据组织架构做一些数据的隔离[元清] 嗯，数据隔离是少不了的，我是把角色作为一个租户id [犀利豆] 先有的系统，后有的权限系统，考虑了很多 接入方怎么快速接入，怎么做到无侵入[元清] 为什么要做到数据库层呢，做到数据库层已经侵入了吧，我这个就是配置一下，就可以了，配置一层filter [犀利豆] 这个的问题是比较具体的，我们的数据要按照公司的组织架构做数据隔离[元清] 都是按照组织架构做数据隔离的[犀利豆] 比如，公司分成了华南，华东，华北。三个地区的用户之间看到的信息是隔离的。[元清] 嗯，这个当然是的，用一个租户id 就可以了[犀利豆] 是的，所以这个租户id 要拼接到sql 里面，查询数据[元清] 哦，你们没有在原有表上面加字段是吧[犀利豆] 这个隔离不是全部隔离，还有横向部门的人，可以看见某几个区域的数据。[元清] 哦，你们是没有改数据库表结构，通过命名方式，来做数据查询么，比如命名规则租户id+xxxx，这个就是树形结构的描述了，我的树形是父拥有所有子的权限，我们还是侵入的，业务端的表都要加租户id 去标示[犀利豆] 没有 系统运行很长一段时间了 不太有时间改 所以想到的方法是用hibernate 的filter 在session层级做的 [元清] 可以的，hibernate我都没用过[犀利豆] 我们也要加租户id，只是已经有了。用hibernate的filter的好处只是，不需要改动controller和service层级，dao层级需要在entity 实际上配置，一个隔离租户的sql，在执行查询的时候，利用aop 把查询的session取出来，自动把过滤的条件拼接在业务sql上[元清] **听起来就很复杂，不过思路还蛮好的，应该也不难维护 来源：云原生后端社区https://www.yuque.com/server_mind/answer

在业务系统中，除了使用主键进行的查询，其他的我都会在测试库上测试其耗时，慢查询的统计主要由运维在做，会定期将业务中的慢查询反馈给我们。 慢查询的优化首先要搞明白慢的原因是什么？ 是查询条件没有命中索引？是load了不需要的数据列？还是数据量太大？ 所以优化也是针对这三个方向来的， 首先分析语句，看看是否load了额外的数据，可能是查询了多余的行并且抛弃掉了，可能是加载了许多结果中并不需要的列，对语句进行分析以及重写。 分析语句的执行计划，然后获得其使用索引的情况，之后修改语句或者修改索引，使得语句可以尽可能的命中索引。 如果对语句的优化已经无法进行，可以考虑表中的数据量是否太大，如果是的话可以进行横向或者纵向的分表。

考试内容一、基础知识1.计算机系统的组成和应用领域。2.计算机软件的基础知识。3.计算机网络的基础知识和应用知识。4.信息安全的基本概念。二、数据结构与算法1.数据结构、算法的基本概念。2.线性表的定义、存储和运算。3.树形结构的定义、存储和运算。4.排序的基本概念和排序方法。5.检索的基本概念和检索算法。三、操作系统1.操作系统的基本概念、主要功能和分类。2.进程、线程、进程间的通信的基本概念。3.存储管理、文件管理、设备管理的主要技术。4.典型操作系统的应用。四、数据库系统的基本原理1.数据库的基本概念，数据库系统的组成。2.数据模型概念和主要的数据模型。3.关系数据模型的基本概念，关系操作和关系代数。4.结构化查询语言SQL。5.事务管理、并发控制、故障恢复的基本概念。五、数据库设计和数据库应用1.关系数据库的规范化理论。2.数据库设计的目标、内容和方法。3.数据库应用开发工具。4.数据库技术发展。六、上机操作1.掌握计算机基本操作。2.掌握C语言程序设计基本技术、编程和调试。3.掌握与考试内容相关的知识的上机应用。其实三级数据库广度挺大，没什么深度，就算有几项知识不熟悉也没关系，但像C语言这样的基础知识应该打好一点，市场上的同类书都差不多，没什么特别的，你如果有时间可以买一本回来仔细看，我觉得只要真正仔细看了，肯定能过的（我以前就是没仔细看书，结果考的时候发现很多题目似曾相识，好后悔啊……），时间不是很多的话建议多做以前的题目，重复的几率很高，而且你想，总共就那么些个知识，又不能出太深，出不了什么新题的，考过的都知道，大差不离。

4V 第一个V——高容量 这个最好理解，数据量一定要大，才好意思称自己为大数据嘛。大到什么程度呢？依目前行情来看，至少也要到TB级，很多案例都是PB甚至更高。但如果是GB级，非说自己是大数据也不是不可以，就是有点无颜见江东父老啊…… 第二个V——多样化 这个很关键了！是区别于以往海量数据挖掘的最主要特征。它有两层含义，一是数据来源多样化，系统数据、设备日志、传感器、文件系统等等来源。二是数据结构多样化，这是核心特征！要包含结构化数据、非结构数据（包括所谓半结构化数据）。 总结起来就是，多源异构。这就是为什么有人认为使用NoSQL数据库（如MongoDB）就是大数据了，因为满足了多样化的特征，但其实还不够。 第三个V——高速 即时效性，基本上至少也要达到亿级数据一秒查询，做的比较好的可以达到千亿级数据一秒查询。这个特征几乎决定了传统技术架构无法满足要求，因此Hadoop架构的出现催化了大数据的发展，也是有人认为Hadoop就是大数据的原因。 第四个V——价值 这个很好理解，数据一定要有价值、而后才能产生价值。就好比存商品的叫才能仓库，存垃圾的叫垃圾填满坑一样。没价值的数据就像一个垃圾填满坑，这也是为什么数据治理在大数据实施中非常重要的原因之一。 最后，也是最重要的，以上4个V是逻辑与的关系，即需同时、注意是同时满足上述四个特征，就可以放心的说自己是大数据了！

数据库课程设计 “数据库课程设计”是数据库系统及应用课程的后续实验课，是进一步巩固学生的数据库知识，加强学生的实际动手能力和提高学生综合素质。 一、 课程设计目的 课程设计为学生提供了一个既动手又动脑，独立实践的机会，将课本上的理论知识和实际有机的结合起来，锻炼学生的分析解决实际问题的能力。提高学生适应实际，实践编程的能力。课程设计的目的： 1. 加深对数据库原理、程序设计语言的理论知识的理解和应用水平； 2. 在理论和实验教学基础上进一步巩固已学基本理论及应用知识并加以综合提高； 3. 学会将知识应用于实际的方法，提高分析和解决问题的能力，增强动手能力； 4. 为毕业设计和以后工作打下必要基础。 二、课程设计要求 运用数据库原理的基本理论与应用知识，在微机RDBMS(SQL Server)的环境上建立一个数据库应用系统。要求把现实世界的事物及事物之间的复杂关系抽象为信息世界的实体及实体之间联系的信息模型，再转换为机器世界的数据模型和数据文件，并对数据文件实施检索、更新和控制等操作。 1. 用E-R图设计选定题目的信息模型； 2. 设计相应的关系模型，确定数据库结构； 3. 分析关系模式各属于第几范式，阐明理由； 4. 设计应用系统的系统结构图，确定系统功能； 5. 通过设计关系的主码约束、外码约束和使用CHECK实现完整性控制； 6. 为参照关系设计插入、删除、修改触发器； 7. 实现应用程序设计、编程、优化功能； 8. 对系统的各个应用程序进行集成和调试，进一步优化系统功能、改善系统用户界面完成实验内容所指定的各项要求； 9. 分析遇到的问题，总结并写出课程设计报告； 10. 自我评价 三、实验环境 开发环境VC++、C#、ASP或JAVA；ODBC/JDBC；数据库SQL Server 四、上机实现内容 1. 创建数据库的结构 2. 创建各基本表的结构 3. 编制系统各功能模块，完成数据的管理（增、删、改）及统计查询。对于程序运行界面不做考核的重点。 五、课程设计考核 1.对学生到实验室的情况进行不定时统计； 2.出勤率+课程设计报告+课程设计所开发的应用系统+其他（上机抽查和提问）=综合评定成绩。 3.课程设计结束时请将下列资料上交： （1） 课程设计报告； （2） 所开发的应用系统的源程序、安装和使用说明； （3） 将（1）（2）中的资料压缩成一个压缩包，压缩包文件的命名规则：班级+学号（末2位）+姓名（例如：计科090101王鹏晓）； （4） 班长将本班每人的（3）中的压缩包刻录成光盘连同打印的课程设计报告收齐，交给任课教师。 附录﹑课程设计题目 题目1：课程设计选题管理系统（1，24） 包括三大模块：  课程设计题目维护与查询：题目的添加、修改和删除；按题目类型、名称和关键字查询以及已选与未选题目的查询；  学生信息维护与查询；  学生选题维护与管理：学生选题及查询； 具体功能细化：  前台学生选题：学生上网登录系统进行选题；  前台教师出题：  教师添加、修改和删除题目；  教师确认学生的选题；  后台管理出题和选题  添加用户及权限 题目2：书店管理系统（23） 包括四大模块：  售书（图书销售管理及销售统计，查询）  进书（通过书目，向发行商下定单订购图书）  库存（图书库存，统计）  相关查询 题目3：图书馆管理系统（11） 包括四大模块：  图书的查询  借书  还书  图书的预约 题目4：库存管理系统（8） 包括四大模块：  商品目录建立  商品入库管理  商品出库管理  商品库存查询 题目5：工资管理系统（1 人）41 包括四大模块：  系统数据初始化  员工基本信息数据的输入、修改、删除；  员工个人信息及工资表的查询；  员工工资的计算； 参考数据如下：  员工基本状况：包括员工号、员工姓名、性别、所在部门、工资级别、工资等级等。  工资级别和工资金额：包括工资等级、工资额。  企业部门及工作岗位信息：包括部门名称、工作岗位名称、工作岗位工资等。  工龄和工资金额：包括工龄及对应工资额。  公司福利表：包括福利名称、福利值。  工资信息：包括员工号、员工姓名、员工基础工资、员工岗位工资、员工工龄工资、公司福利、员工实得工资。 题目6：酒店客房管理系统 （1 人）14，26 包括四大模块：  前台操作：包括开房登记、退房结账和房状态查看  预订管理：包括预订房间、预订入住和解除预订  信息查询：包括在住客人列表、预订客人列表和历史客人列表  报表统计：包括开房记录统计、退房结账和预订房间统计  员工基本信息数据的输入、修改、删除； 参考数据如下：  住店管理：客人姓名、证件号码、房号、入住时期、预计离开日期、结账离开日期、应付金额  客人信息：姓名、性别、证件类型、证件号码、联系电话  房间信息：房号、房类型、价格、押金、房状态 预订房间  客人姓名、性别、房类型、房号、价格、证件类型、证件号码、联系电话、入住日期、预计离开日期、历史信息 题目7：旅行社管理信息系统（1 人）3 包括如下模块：  旅游团队、团队团员及旅游路线相关信息的输入  旅游团队、团队团员及旅游路线相关信息的维护（修改、浏览、删除和撤销）  旅游团队管理信息的查询（如按团队编号）  团队团员基本情况的查询（可选多种方式）  旅游路线相关信息的查询（如按线路编号）  旅游路线排行榜发布。  数据备份，更改密码。 参考数据如下：  团员信息表（路线编号，团队编号，团员编号，姓名，性别，电话，通信地址，身份证号码， 团费交否，备注）  线路信息表（路线名称，团费，简介，图形，路线编号）  团队信息表（团队编号，路线编号，团员人数，出发日期，返程日期）  旅游团队信息表（团队编号，团队负责人，团员人数，建团时间，是否出发，团费，盈亏） 密码信息（操作员，密码） 题目8：报刊订阅管理系统 （1 人）25，35 包括如下模块：  登录功能：登录统为身份验证登录。分为管理员登录和一般用户登录。分别通过不 同的用户名和密码进入报刊订阅管理界面，新的用户需要注册。  录入新信息功能：对于管理员，包括新用户信息和新报刊信息的录入功能，信息一旦 提交就存入到后台数据库中；普通用户自行注册进行可以修改个人信息。  订阅功能：用户可以订阅报刊，系统自动计算所需金额，并显示在界面上；管理员不 可订阅报刊，必须以用户身份订阅报刊。  查询功能：用户可以查询并显示自己所订阅的信息；管理员可以按人员、报刊、部门 分类查询。查询出的信息显示在界面上,并且可以预览和打印出结果。  统计功能：管理员可以按用户、部门、报刊统计报刊的销售情况，并对一些重要的订 阅信息进行统计；普通用户可以统计出自己的订阅情况，并且可以预览和打印出结果。  系统维护功能：数据的安全管理，主要是依靠管理员对数据库里的信息进行备份和恢 复，数据库备份后，如果出了什么意外可以恢复数据库到当时备份的状态，这提高了系统和 数据的安全性，有利于系统的维护 参考数据如下：  管理员表（Adminuser） ：管理员名、密码。  部门表（Department） ：部门号，部门名。  用户表（Users） ：用户账号、密码、真实姓名、身 份证号、联系电话，联系地址，部门号（和部门表有关）等。  报刊类别表（NewspaperClass） ：分类编号、 分类名称。  报刊信息表（Newspaper） ：报刊代号、报刊名称、出版 报社、出版周期、季度报价、内容介绍、分类编号（和报刊类别表有关）等。  订单表（Order） ：订单编号、用户编号、报刊代号、订阅份数、订阅月数等。 题目9：计算机等级考试教务管理系统（2 人）32 包括四大模块：  用户设置：对考点代码，考点名称进行设置，设置用户与密码；系统复位：即清除上一次考试数据（在之前存入历史）  报名管理： 报各库录入（姓名不能不空，之间不能有空格） 增加、删除、修改、浏览  准考证管理：准考证生成规则：xxx+yy+zz+kk，其中 XXX 为考点代码；YY 为语言代码，XX 为考场号，KK 为座位号 同一级别、语言应根据报名初始库信息按随机数生成准考证，同一考点最多可有 99*30=2970 名考生；如已生成准考证号，再重新生成准考证号，应该给予提示。 准考证打印  考务管理：考生信息查询、浏览、打印  成绩管理：成绩数据录入、接收 成绩合成（总成绩=笔试成绩*0.6+上机成绩*0.4）,按大于或等于 60 合格 参考数据如下：  初始报名表（准考证号（为空） ，报名号（主键） ，级别+语言种类（外键） ，姓名，性别， 出生年份，民族，身份证号，联系地址，联系电话，照片，备注，参加培训）  含准考证号的报名表（准考证号（为主键） ，报名号，级别+语言种类（外键） ，姓名，性别， 出生年份，民族，身份证号，联系地址，联系电话，照片，备注，参加培训）  成绩表（准考证号，笔试成绩，上机成绩，总成绩） 级别语言代码表（级别语言代码，级别+语言）  用户信息表（考点代码，考点名称，用户名，密码） 题目10：人事管理系统（1 人）21 包括四大模块：  登录管理：包括操作员管理，口令设置，权限管理  人员管理：包括人事数据维护、人事信息查询和人事信息统计  工资管理  部门管理：包括部门表，职称表和年份表  查询及报表打印 参考数据如下：  人事表（编号，姓名，性别，出生日期，工作日期，部门代码，职称，婚否，简历，相片）  工资表（基本工资，岗位津贴，奖励，应发工资，水电，保险，实发工资）  部门表（代码，部门名称）  职称表（职称代码，职称名称）  年份表（年份代码，年份名称）  操作员表（操作员代码，操作员姓名，口令，部门，电话） 系统日志表（操作员代号，操作员姓名，登录时间，离开时间） 题目11：商品销售管理系统（1 人）19 包括四大模块：  用户登录  基本信息管理：包括销售情况、商品信息、库存表、员工表等信息的录入、浏览、修改、撤销、删除和查询等  商品销售管理：包括商品售出、退回和入库  盘点：包括库存盘点、当日销售盘点 参考数据如下：  商品信息表（商品编号，商品名称，品牌，型号，销售单价） 商品编号=类别代码（1 位）+品名代码（1 位）+品牌代码（2 位）+型号代码（2 位）  销售情况表（成交编号，商品编号，销售数量，总金额，销售日期，员工编号）  库存表（商品编号，供货商编号，进货日期，进货价，库存数量）  员工表（员工编号，员工姓名，性别，基本工资，职务，密码）  供货商表（供货商编号，供货商名称，所在地，联系电话）  员工资料表（员工编号，员工姓名，是否党员，简历，照片） 题目12：学生成绩管理系统（1 人）29 包括四大模块：  基本数据管理：包括院系管理，专业管理（设置院系下面的专业），班级管理（设置专业下面的班级），课程管理（设置相应专业下面的课程）  学生信息管理：包括基本信息录入、基本信息修改  学生成绩管理：包括学生成绩录入、学生成绩修改  信息查询：包括基本信息查询、成绩信息查询、学校人数统计  系统管理：用户管理、数据备份和系统帮助 参考数据如下：  院系信息（院系代码，院系名称）  院系专业信息（班级、院系代码，专业）  学生基本信息（班号，学号，姓名，性别，出生年月，籍贯，政治面貌，身份证号，入学年月，家庭地址，邮政编码，图片信息，备注）  学生成绩表（学号，课号，成绩，备注）  课程表（课号，课程名称，学期，备注）  班表（班号，班级名称）  用户信息表（用户名，密码，用户标识） 题目13：火车售票管理系统（4 人）36 包括四大模块：  售票管理  订票管理  信息查询  系统维护 参考数据如下：  车次信息表（车次，始发站，终点站，发车时间，到达时间）  订票信息表（车次，座位号，发车时期，发车时间，座位等级，票价）  车次座位等级分配及座位占用表（车次，座位号，座位等级，票价，占用标志）  用户信息表（用户名，密码，用户标识） 题目14：小型物业管理系统（1 人） 包括四大模块：  房源管理：对原始资料的录入、修改、查询和刷新。一般用户可以查询与房间有关 的统计资料；物业主管可其进行增、删、改、插等操作  租房管理：对房产出租，退租以及租房面积调整。其中物业主管可对其进行房租金 额计算和收款操作，一般用户对其查询  水电处理：根据租房资料，结合当月水、电量进行分摊，完成应收水电费。其中物 业主管对其进行计算，其他查询  交款处理：提供收款和发票打印以及交款数据查询  查询处理：对租房资料、交款资料，发票资料进行查询 参考数据如下：  房源资料（名称，面积，月租，物业，仓库）  租房资料（名称，面积，单位，月租，物业，押金，仓库）  水电资料（单位，电量，水量，电费，水费）  交费资料（收费项目，应收日期，应收金额，已收金额，未收金额，本次收款）  发票资料（单位，房租，电费，水费，物业）  权限资料（用户，密码，房源管理，租房管理，水电管理，交费管理，发票管理，系统维护） 其中系统管理员，有权进行系统维护；单位内部物业主管，有权进行物业资源调配、单元出 租，退租和收款开票操作；物业管理员，有权进行水电处理和收款处理等操行；租户代表， 有权进行种类费的查询操作 题目15：机房收费管理系统（1 人）7，34 包括四大模块：  登录模块  上机管理模块 说明：上机登记时，余额不足 3 元或卡处于挂失状态，则拒绝登记 每位同学的一次上机形成一条记录，每 36S 遍历一次上机记录表，对表中所有正上机字段为 TRUE 的记录的上机用时增加 36S,同时从上机卡表的余额减少  上机卡管理模块  充值挂失模块  查找统计模块：统计某天上机的总时数、每次上机的平均时数和机房的收入；某学 生上机的次数、上机总时数、每次上机平均时间；挂失和查询余 参考数据如下：  上机卡（卡号，姓名，专业班级，余额，状态） 状态的取值有：正常（能自费上机）  挂失上机记录（卡号，上机日期，开始时间，上机用时，正上机，管理号代码），上机用时记录学生上机时间（S）；正上机是一个布尔型，为 True 表示正上机，每 36 秒刷新 其上机用时并扣除上机费用，为 False 表示上机结束。上机记录表永久保存，用于事后查询 和统计 管理员（代码，姓名，口令）  题目16：高校药房管理（1 人）31 包括四大模块：  基础数据处理：包括医生和药剂师名单的录入，修改，删除及查询  营业数据处理：包括药品进货上柜，处理划价，配药，柜存药品查询，处方综合查 询，交接班结转清。 参考数据如下：  药品信息表（货号，货名，计量单位，进货数量，进货单价，出售单价，进货日期，收货人 和供应商）  处方信息（编号，患者姓名，医生姓名，药剂师姓名，处方日期，配药日期） 处方药品信息（处方编号，药品货号，计量单位，配药数量，销售单价，已配药否）  医生名单和药剂师名单表（姓名）  题目17：考勤管理系统（2 人）40 包括四大模块：  记录每个员工每天所有进入公司的时刻和离开公司的时刻。  每天结束时自动统计当天的工作时间  每天结束时自动统计当天迟到或早退的次数。  对于弹性工作制，每天结束时自动统计当月的工时，并自动算出当月欠缺或富余的 时间  每个月末统计该月的工作时间判断是束足够  每个月末统计该月的工作天数并判断是否足够  管理人员查询并修改工作时间（特殊情况下修改）  管理人员账户管理（如设置密码等）  管理人员设定早退及迟到的条件，每个月的工作时间  管理人员设定每个月的工作日期及放假日期 参考数据如下：  员工信息(工号，姓名，年龄，入职时间，职位，性别，密码)  配置信息（上班时间小时，上班时间分钟，下班时间小时，下班时间分钟，每天工作时间）  每月统计数据表（工号，姓名，剩余的时间，迟到的次数，早退的次数，工作天数）  每天统计信息表（工号，姓名，小时，分钟，动作，时间） 其中动作指的时入或离开公司  题目18：单位房产管理系统（2 人）33，10 包括四大模块：  系统模块：完成数据库维护、系统关闭功能  物业费用模块：完成本月物业的计费、历史资料查询和财务部门接口传送数据、物 业相关费用单价设置  房屋资源模块：对房屋资源进行添加、列表显示、查询  职工信息模块：对职工进行添加、列表显示、查询以及相应部门、职务进行维护  帮助模块：对用户使用本系统提供在线帮助 参考数据如下：  职工（编号，姓名，性别，参加工作时间，行政职务，专业技术职务，评上最高行政职务时 间，评上最高专业技术职务时间，双职工姓名，现居住房号，档案号，房产证号，所在部门 编号，是否为户主）  部门（编号，部门名称） 住房级别表（编号，级别，住房标准，控制标准，级别分类）  房产情况（编号，房号，使用面积，现居住人 id，上一个居住人 id,最早居住人 ID,阳台面积）  物业费用（编号，房号，水基数，水现在值，电基数，电现在值，燃气基数，燃气现在值， 当前年份，当前月份）  价格标准（编号，水单价，电单价，燃气单价） 题目19：标准化考试系统 （2 人）15，39 功能要求： 设计一个简单的标准化考试系统，仅有单项选择题、多项选择题和判断题功能即可。 包括四大模块：  题库管理：实现试题的录入、修改、删除功能；  考试子系统：能够实现考生做题、结果自动存入到数据库中，有时间提示；  选择身份(登录)功能：系统能够记录考生输入的登录信息及交卷信息；  自动评分功能：考生交卷后能自动评分；  查看成绩功能：能够查询考生相关信息(包含成绩等)。 参考数据如下： 其它可供选择的题目： 网上教务评教系统130，127，133 16 学生日常行为评分管理系统232，110，230 网上鲜花店 38 基于BS结构的工艺品销售系统12 基于BS结构的校园二手物品交易网站 37 大学生就业管理系统201，208，234 题库及试卷管理系统 数据库原理及应用 课程设计报告 题目： 课程设计选题管理系统 所在学院： 班 级： 学 号： 姓 名： 李四 指导教师： 2011年12月 日 目录 一、 概述 二、需求分析 三、概念设计 四、逻辑设计 五、系统实现 六、小结 一、概述

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

参考：https://www.iteblog.com/archives/2530.html分布式和去中心化（Distributed and Decentralized）Cassandra 是分布式的，这意味着它可以运行在多台机器上，并呈现给用户一个一致的整体。事实上，在一个节点上运行 Cassandra 是没啥用的，虽然我们可以这么做，并且这可以帮助我们了解它的工作机制，但是你很快就会意识到，需要多个节点才能真正了解 Cassandra 的强大之处。它的很多设计和实现让系统不仅可以在多个节点上运行，更为多机架部署进行了优化，甚至一个 Cassandra 集群可以运行在分散于世界各地的数据中心上。你可以放心地将数据写到集群的任意一台机器上，Cassandra 都会收到数据。对于很多存储系统（比如 MySQL, Bigtable），一旦你开始扩展它，就需要把某些节点设为主节点，其他则作为从节点。但 Cassandra 是无中心的，也就是说每个节点都是一样的。与主从结构相反，Cassandra 的协议是 P2P 的，并使用 gossip 来维护存活或死亡节点的列表。关于 gossip 可以参见《分布式原理：一文了解 Gossip 协议》。去中心化这一事实意味着 Cassandra 不会存在单点失效。Cassandra 集群中的所有节点的功能都完全一样， 所以不存在一个特殊的主机作为主节点来承担协调任务。有时这被叫做服务器对称（server symmetry）。综上所述，Cassandra 是分布式、无中心的，它不会有单点失效，所以支持高可用性。弹性可扩展（Elastic Scalability）可扩展性是指系统架构可以让系统提供更多的服务而不降低使用性能的特性。仅仅通过给现有的机器增加硬件的容量、内存进行垂直扩展，是最简单的达到可扩展性的手段。而水平扩展则需要增加更多机器，每台机器提供全部或部分数据，这样所有主机都不必负担全部业务请求。但软件自己需要有内部机制来保证集群中节点间的数据同步。弹性可扩展是指水平扩展的特性，意即你的集群可以不间断的情况下，方便扩展或缩减服务的规模。这样，你就不需要重新启动进程，不必修改应用的查询，也无需自己手工重新均衡数据分布。在 Cassandra 里，你只要加入新的计算机，Cassandra 就会自动地发现它并让它开始工作。高可用和容错（High Availability and Fault Tolerance）从一般架构的角度来看，系统的可用性是由满足请求的能力来量度的。但计算机可能会有各种各样的故障，从硬件器件故障到网络中断都有可能。如何计算机都可能发生这些情况，所以它们一般都有硬件冗余，并在发生故障事件的情况下会自动响应并进行热切换。对一个需要高可用的系统，它必须由多台联网的计算机构成，并且运行于其上的软件也必须能够在集群条件下工作，有设备能够识别节点故障，并将发生故障的中端的功能在剩余系统上进行恢复。Cassandra 就是高可用的。你可以在不中断系统的情况下替换故障节点，还可以把数据分布到多个数据中心里，从而提供更好的本地访问性能，并且在某一数据中心发生火灾、洪水等不可抗灾难的时候防止系统彻底瘫痪。可调节的一致性（Tuneable Consistency）2000年，加州大学伯克利分校的 Eric Brewer 在 ACM 分布式计算原理会议提出了著名的 CAP 定律。CAP 定律表明，对于任意给定的系统，只能在一致性（Consistency）、可用性（Availability）以及分区容错性（Partition Tolerance）之间选择两个。关于 CAP 定律的详细介绍可参见《分布式系统一致性问题、CAP定律以及 BASE 理论》以及《一篇文章搞清楚什么是分布式系统 CAP 定理》。所以 Cassandra 在设计的时候也不得不考虑这些问题，因为分区容错性这个是每个分布式系统必须考虑的，所以只能在一致性和可用性之间做选择，而 Cassandra 的应用场景更多的是为了满足可用性，所以我们只能牺牲一致性了。但是根据 BASE 理论，我们其实可以通过牺牲强一致性获得可用性。Cassandra 提供了可调节的一致性，允许我们选定需要的一致性水平与可用性水平，在二者间找到平衡点。因为客户端可以控制在更新到达多少个副本之前，必须阻塞系统。这是通过设置副本因子（replication factor）来调节与之相对的一致性级别。通过副本因子（replication factor），你可以决定准备牺牲多少性能来换取一致性。 副本因子是你要求更新在集群中传播到的节点数（注意，更新包括所有增加、删除和更新操作）。客户端每次操作还必须设置一个一致性级别（consistency level）参数，这个参数决定了多少个副本写入成功才可以认定写操作是成功的，或者读取过程中读到多少个副本正确就可以认定是读成功的。这里 Cassandra 把决定一致性程度的权利留给了客户自己。所以，如果需要的话，你可以设定一致性级别和副本因子相等，从而达到一个较高的一致性水平，不过这样就必须付出同步阻塞操作的代价，只有所有节点都被更新完成才能成功返回一次更新。而实际上，Cassandra 一般都不会这么来用，原因显而易见（这样就丧失了可用性目标，影响性能，而且这不是你选择 Cassandra 的初衷）。而如果一个客户端设置一致性级别低于副本因子的话，即使有节点宕机了，仍然可以写成功。总体来说，Cassandra 更倾向于 CP，虽然它也可以通过调节一致性水平达到 AP；但是不推荐你这么设置。面向行（Row-Oriented）Cassandra 经常被看做是一种面向列（Column-Oriented）的数据库，这也并不算错。它的数据结构不是关系型的，而是一个多维稀疏哈希表。稀疏（Sparse）意味着任何一行都可能会有一列或者几列，但每行都不一定（像关系模型那样）和其他行有一样的列。每行都有一个唯一的键值，用于进行数据访问。所以，更确切地说，应该把 Cassandra 看做是一个有索引的、面向行的存储系统。Cassandra 的数据存储结构基本可以看做是一个多维哈希表。这意味着你不必事先精确地决定你的具体数据结构或是你的记录应该包含哪些具体字段。这特别适合处于草创阶段，还在不断增加或修改服务特性的应用。而且也特别适合应用在敏捷开发项目中，不必进行长达数月的预先分析。对于使用 Cassandra 的应用，如果业务发生变化了，只需要在运行中增加或删除某些字段就行了，不会造成服务中断。当然， 这不是说你不需要考虑数据。相反，Cassandra 需要你换个角度看数据。在 RDBMS 里， 你得首先设计一个完整的数据模型， 然后考虑查询方式， 而在 Cassandra 里，你可以首先思考如何查询数据，然后提供这些数据就可以了。灵活的模式（Flexible Schema）Cassandra 的早期版本支持无模式（schema-free）数据模型，可以动态定义新的列。 无模式数据库（如 Bigtable 和 MongoDB）在访问大量数据时具有高度可扩展性和高性能的优势。 无模式数据库的主要缺点是难以确定数据的含义和格式，这限制了执行复杂查询的能力。为了解决这些问题，Cassandra 引入了 Cassandra Query Language（CQL），它提供了一种通过类似于结构化查询语言（SQL）的语法来定义模式。 最初，CQL 是作为 Cassandra 的另一个接口，并且基于 Apache Thrift 项目提供无模式的接口。 在这个过渡阶段，术语“模式可选”（Schema-optional）用于描述数据模型，我们可以使用 CQL 的模式来定义。并且可以通过 Thrift API 实现动态扩展以此添加新的列。 在此期间，基础数据存储模型是基于 Bigtable 的。从 3.0 版本开始，不推荐使用基于 Thrift API 的动态列创建的 API，并且 Cassandra 底层存储已经重新实现了，以更紧密地与 CQL 保持一致。 Cassandra 并没有完全限制动态扩展架构的能力，但它的工作方式却截然不同。 CQL 集合（比如 list、set、尤其是 map）提供了在无结构化的格式里面添加内容的能力，从而能扩展现有的模式。CQL 还提供了改变列的类型的能力，以支持 JSON 格式的文本的存储。因此，描述 Cassandra 当前状态的最佳方式可能是它支持灵活的模式。高性能（High Performance）Cassandra 在设计之初就特别考虑了要充分利用多处理器和多核计算机的性能，并考虑在分布于多个数据中心的大量这类服务器上运行。它可以一致而且无缝地扩展到数百台机器，存储数 TB 的数据。Cassandra 已经显示出了高负载下的良好表现，在一个非常普通的工作站上，Cassandra 也可以提供非常高的写吞吐量。而如果你增加更多的服务器，你还可以继续保持 Cassandra 所有的特性而无需牺牲性能。

Java架构师，首先要是一个高级java攻城狮，熟练使用各种框架，并知道它们实现的原理。jvm虚拟机原理、调优，懂得jvm能让你写出性能更好的代码;池技术，什么对象池，连接池，线程池…… 　　 Java反射技术，写框架必备的技术，但是有严重的性能问题，替代方案java字节码技术;nio，没什么好说的，值得注意的是”直接内存”的特点，使用场景;java多线程同步异步;java各种集合对象的实现原理，了解这些可以让你在解决问题时选择合适的数据结构，高效的解决问题，比如hashmap的实现原理，好多五年以上经验的人都弄不清楚，还有为什扩容时有性能问题?不弄清楚这些原理，就写不出高效的代码，还会认为自己做的很对;总之一句话越基础的东西越重要，很多人认为自己会用它们写代码了，其实仅仅是知道如何调用api而已,离会用还差的远。 　　 熟练使用各种数据结构和算法，数组、哈希、链表、排序树…，一句话要么是时间换空间要么是空间换时间，这里展开可以说一大堆，需要有一定的应用经验，用于解决各种性能或业务上的问题。 　　 熟练使用linux操作系统，必备，没什么好说的 。 　　 熟悉tcp协议，创建连接三次握手和断开连接四次握手的整个过程，不了解的话，无法对高并发网络应用做优化; 熟悉http协议，尤其是http头，我发现好多工作五年以上的都弄不清session和cookie的生命周期以及它们之间的关联。 　　 系统集群、负载均衡、反向代理、动静分离，网站静态化 。 　　 分布式存储系统nfs,fastdfs,tfs,Hadoop了解他们的优缺点，适用场景 。 　　 分布式缓存技术memcached,redis，提高系统性能必备，一句话，把硬盘上的内容放到内存里来提速，顺便提个算法一致性hash 。 　　 工具nginx必备技能超级好用，高性能，基本不会挂掉的服务器，功能多多，解决各种问题。 　　 数据库的设计能力，mysql必备，最基础的数据库工具，免费好用，对它基本的参数优化，慢查询日志分析，主从复制的配置，至少要成为半个mysql dba。其他nosql数据库如mongodb。 　　 还有队列中间件。如消息推送，可以先把消息写入数据库，推送放队列服务器上，由推送服务器去队列获取处理，这样就可以将消息放数据库和队列里后直接给用户反馈，推送过程则由推送服务器和队列服务器完成，好处异步处理、缓解服务器压力，解藕系统。　　 以上纯粹是常用的技术，还有很多自己慢慢去摸索吧;因为要知道的东西很多，所以要成为一名合格的架构师，必须要有强大的自学能力，没有人会手把手的教给你所有的东西。 　　 想成为架构师不是懂了一大堆技术就可以了，这些是解决问题的基础、是工具，不懂这些怎么去提解决方案呢?这是成为架构师的必要条件。 　　 架构师要针对业务特点、系统的性能要求提出能解决问题成本最低的设计方案才合格，人家一个几百人用户的系统，访问量不大，数据量小，你给人家上集群、上分布式存储、上高端服务器，为了架构而架构，这是最扯淡的，架构师的作用就是第一满足业务需求，第二最低的硬件网络成本和技术维护成本。 　　 架构师还要根据业务发展阶段，提前预见发展到下一个阶段系统架构的解决方案，并且设计当前架构时将架构的升级扩展考虑进去，做到易于升级;否则等系统瓶颈来了，出问题了再去出方案，或现有架构无法扩展直接扔掉重做，或扩展麻烦问题一大堆，这会对企业造成损失。Java架构师学习路线图如：https://yq.aliyun.com/articles/225941?spm=5176.8091938.0.0.qyp0tC

面试官心理分析 这个问题是肯定要问的，说白了，就是看你有没有实际干过 es，因为啥？其实 es 性能并没有你想象中那么好的。很多时候数据量大了，特别是有几亿条数据的时候，可能你会懵逼的发现，跑个搜索怎么一下 5~10s，坑爹了。第一次搜索的时候，是 5~10s，后面反而就快了，可能就几百毫秒。 你就很懵，每个用户第一次访问都会比较慢，比较卡么？所以你要是没玩儿过 es，或者就是自己玩玩儿 demo，被问到这个问题容易懵逼，显示出你对 es 确实玩儿的不怎么样？ 面试题剖析 说实话，es 性能优化是没有什么银弹的，啥意思呢？就是不要期待着随手调一个参数，就可以万能的应对所有的性能慢的场景。也许有的场景是你换个参数，或者调整一下语法，就可以搞定，但是绝对不是所有场景都可以这样。 性能优化的杀手锏——filesystem cache 你往 es 里写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 filesystem cache 里面去。 es 的搜索引擎严重依赖于底层的 filesystem cache，你如果给 filesystem cache 更多的内存，尽量让内存可以容纳所有的 idx segment file 索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。 性能差距究竟可以有多大？我们之前很多的测试和压测，如果走磁盘一般肯定上秒，搜索性能绝对是秒级别的，1秒、5秒、10秒。但如果是走 filesystem cache，是走纯内存的，那么一般来说性能比走磁盘要高一个数量级，基本上就是毫秒级的，从几毫秒到几百毫秒不等。 这里有个真实的案例。某个公司 es 节点有 3 台机器，每台机器看起来内存很多，64G，总内存就是 64 * 3 = 192G。每台机器给 es jvm heap 是 32G，那么剩下来留给 filesystem cache 的就是每台机器才 32G，总共集群里给 filesystem cache 的就是 32 * 3 = 96G 内存。而此时，整个磁盘上索引数据文件，在 3 台机器上一共占用了 1T 的磁盘容量，es 数据量是 1T，那么每台机器的数据量是 300G。这样性能好吗？ filesystem cache 的内存才 100G，十分之一的数据可以放内存，其他的都在磁盘，然后你执行搜索操作，大部分操作都是走磁盘，性能肯定差。 归根结底，你要让 es 性能要好，最佳的情况下，就是你的机器的内存，至少可以容纳你的总数据量的一半。 根据我们自己的生产环境实践经验，最佳的情况下，是仅仅在 es 中就存少量的数据，就是你要用来搜索的那些索引，如果内存留给 filesystem cache 的是 100G，那么你就将索引数据控制在 100G 以内，这样的话，你的数据几乎全部走内存来搜索，性能非常之高，一般可以在 1 秒以内。 比如说你现在有一行数据。id,name,age .... 30 个字段。但是你现在搜索，只需要根据 id,name,age 三个字段来搜索。如果你傻乎乎往 es 里写入一行数据所有的字段，就会导致说 90% 的数据是不用来搜索的，结果硬是占据了 es 机器上的 filesystem cache 的空间，单条数据的数据量越大，就会导致 filesystem cahce 能缓存的数据就越少。其实，仅仅写入 es 中要用来检索的少数几个字段就可以了，比如说就写入 es id,name,age 三个字段，然后你可以把其他的字段数据存在 mysql/hbase 里，我们一般是建议用 es + hbase 这么一个架构。 hbase 的特点是适用于海量数据的在线存储，就是对 hbase 可以写入海量数据，但是不要做复杂的搜索，做很简单的一些根据 id 或者范围进行查询的这么一个操作就可以了。从 es 中根据 name 和 age 去搜索，拿到的结果可能就 20 个 doc id，然后根据 doc id 到 hbase 里去查询每个 doc id 对应的完整的数据，给查出来，再返回给前端。 写入 es 的数据最好小于等于，或者是略微大于 es 的 filesystem cache 的内存容量。然后你从 es 检索可能就花费 20ms，然后再根据 es 返回的 id 去 hbase 里查询，查 20 条数据，可能也就耗费个 30ms，可能你原来那么玩儿，1T 数据都放 es，会每次查询都是 5~10s，现在可能性能就会很高，每次查询就是 50ms。 数据预热 假如说，哪怕是你就按照上述的方案去做了，es 集群中每个机器写入的数据量还是超过了 filesystem cache 一倍，比如说你写入一台机器 60G 数据，结果 filesystem cache 就 30G，还是有 30G 数据留在了磁盘上。 其实可以做数据预热。 举个例子，拿微博来说，你可以把一些大V，平时看的人很多的数据，你自己提前后台搞个系统，每隔一会儿，自己的后台系统去搜索一下热数据，刷到 filesystem cache 里去，后面用户实际上来看这个热数据的时候，他们就是直接从内存里搜索了，很快。 或者是电商，你可以将平时查看最多的一些商品，比如说 iphone 8，热数据提前后台搞个程序，每隔 1 分钟自己主动访问一次，刷到 filesystem cache 里去。 对于那些你觉得比较热的、经常会有人访问的数据，最好做一个专门的缓存预热子系统，就是对热数据每隔一段时间，就提前访问一下，让数据进入 filesystem cache 里面去。这样下次别人访问的时候，性能一定会好很多。 冷热分离 es 可以做类似于 mysql 的水平拆分，就是说将大量的访问很少、频率很低的数据，单独写一个索引，然后将访问很频繁的热数据单独写一个索引。最好是将冷数据写入一个索引中，然后热数据写入另外一个索引中，这样可以确保热数据在被预热之后，尽量都让他们留在 filesystem os cache 里，别让冷数据给冲刷掉。 你看，假设你有 6 台机器，2 个索引，一个放冷数据，一个放热数据，每个索引 3 个 shard。3 台机器放热数据 index，另外 3 台机器放冷数据 index。然后这样的话，你大量的时间是在访问热数据 index，热数据可能就占总数据量的 10%，此时数据量很少，几乎全都保留在 filesystem cache 里面了，就可以确保热数据的访问性能是很高的。但是对于冷数据而言，是在别的 index 里的，跟热数据 index 不在相同的机器上，大家互相之间都没什么联系了。如果有人访问冷数据，可能大量数据是在磁盘上的，此时性能差点，就 10% 的人去访问冷数据，90% 的人在访问热数据，也无所谓了。 document 模型设计 对于 MySQL，我们经常有一些复杂的关联查询。在 es 里该怎么玩儿，es 里面的复杂的关联查询尽量别用，一旦用了性能一般都不太好。 最好是先在 Java 系统里就完成关联，将关联好的数据直接写入 es 中。搜索的时候，就不需要利用 es 的搜索语法来完成 join 之类的关联搜索了。 document 模型设计是非常重要的，很多操作，不要在搜索的时候才想去执行各种复杂的乱七八糟的操作。es 能支持的操作就那么多，不要考虑用 es 做一些它不好操作的事情。如果真的有那种操作，尽量在 document 模型设计的时候，写入的时候就完成。另外对于一些太复杂的操作，比如 join/nested/parent-child 搜索都要尽量避免，性能都很差的。 分页性能优化 es 的分页是较坑的，为啥呢？举个例子吧，假如你每页是 10 条数据，你现在要查询第 100 页，实际上是会把每个 shard 上存储的前 1000 条数据都查到一个协调节点上，如果你有个 5 个 shard，那么就有 5000 条数据，接着协调节点对这 5000 条数据进行一些合并、处理，再获取到最终第 100 页的 10 条数据。 分布式的，你要查第 100 页的 10 条数据，不可能说从 5 个 shard，每个 shard 就查 2 条数据，最后到协调节点合并成 10 条数据吧？你必须得从每个 shard 都查 1000 条数据过来，然后根据你的需求进行排序、筛选等等操作，最后再次分页，拿到里面第 100 页的数据。你翻页的时候，翻的越深，每个 shard 返回的数据就越多，而且协调节点处理的时间越长，非常坑爹。所以用 es 做分页的时候，你会发现越翻到后面，就越是慢。 我们之前也是遇到过这个问题，用 es 作分页，前几页就几十毫秒，翻到 10 页或者几十页的时候，基本上就要 5~10 秒才能查出来一页数据了。 有什么解决方案吗？ 不允许深度分页（默认深度分页性能很差） 跟产品经理说，你系统不允许翻那么深的页，默认翻的越深，性能就越差。 类似于 app 里的推荐商品不断下拉出来一页一页的 类似于微博中，下拉刷微博，刷出来一页一页的，你可以用 scroll api，关于如何使用，自行上网搜索。 scroll 会一次性给你生成所有数据的一个快照，然后每次滑动向后翻页就是通过游标 scroll_id 移动，获取下一页下一页这样子，性能会比上面说的那种分页性能要高很多很多，基本上都是毫秒级的。 但是，唯一的一点就是，这个适合于那种类似微博下拉翻页的，不能随意跳到任何一页的场景。也就是说，你不能先进入第 10 页，然后去第 120 页，然后又回到第 58 页，不能随意乱跳页。所以现在很多产品，都是不允许你随意翻页的，app，也有一些网站，做的就是你只能往下拉，一页一页的翻。 初始化时必须指定 scroll 参数，告诉 es 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时，否则可能因为超时而失败。 除了用 scroll api，你也可以用 search_after 来做，search_after 的思想是使用前一页的结果来帮助检索下一页的数据，显然，这种方式也不允许你随意翻页，你只能一页页往后翻。初始化时，需要使用一个唯一值的字段作为 sort 字段。 往期回顾： 【Java问答学堂】1期 为什么使用消息队列？消息队列有什么优点和缺点？Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？ 【Java问答学堂】2期 如何保证消息队列的高可用？ 【Java问答学堂】3期 如何保证消息不被重复消费？或者说，如何保证消息消费的幂等性？ 【Java问答学堂】4期 如何保证消息的可靠性传输？（如何处理消息丢失的问题？） 【Java问答学堂】5期 如何保证消息的顺序性？ 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题？ 【Java问答学堂】7期 如果让你写一个消息队列，该如何进行架构设计？ 【Java问答学堂】8期 es 的分布式架构原理能说一下么（es 是如何实现分布式的啊）？ 【Java问答学堂】9期 es 写入数据的工作原理是什么啊？es 查询数据的工作原理是什么啊？

数据可靠性RocketMQ支持异步实时刷盘，同步刷盘，同步Replication，异步ReplicationKafka使用异步刷盘方式，异步Replication/同步Replication总结：RocketMQ的同步刷盘在单机可靠性上比Kafka更高，不会因为操作系统Crash，导致数据丢失。Kafka同步Replication理论上性能低于RocketMQ的同步Replication，原因是Kafka的数据以分区为单位组织，意味着一个Kafka实例上会有几百个数据分区，RocketMQ一个实例上只有一个数据分区，RocketMQ可以充分利用IO Group Commit机制，批量传输数据，配置同步Replication与异步Replication相比，性能损耗约20%~30%，Kafka没有亲自测试过，但是个人认为理论上会低于RocketMQ。性能对比Kafka单机写入TPS约在百万条/秒，消息大小10个字节RocketMQ单机写入TPS单实例约7万条/秒，单机部署3个Broker，可以跑到最高12万条/秒，消息大小10个字节总结：Kafka的TPS跑到单机百万，主要是由于Producer端将多个小消息合并，批量发向Broker。RocketMQ为什么没有这么做？Producer通常使用Java语言，缓存过多消息，GC是个很严重的问题Producer调用发送消息接口，消息未发送到Broker，向业务返回成功，此时Producer宕机，会导致消息丢失，业务出错Producer通常为分布式系统，且每台机器都是多线程发送，我们认为线上的系统单个Producer每秒产生的数据量有限，不可能上万。缓存的功能完全可以由上层业务完成。单机支持的队列数Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长。Kafka分区数无法过多的问题RocketMQ单机支持最高5万个队列，Load不会发生明显变化队列多有什么好处？单机可以创建更多Topic，因为每个Topic都是由一批队列组成Consumer的集群规模和队列数成正比，队列越多，Consumer集群可以越大消息投递实时性Kafka使用短轮询方式，实时性取决于轮询间隔时间，0.8以后版本支持长轮询。RocketMQ使用长轮询，同Push方式实时性一致，消息的投递延时通常在几个毫秒。消费失败重试Kafka消费失败不支持重试。RocketMQ消费失败支持定时重试，每次重试间隔时间顺延总结：例如充值类应用，当前时刻调用运营商网关，充值失败，可能是对方压力过多，稍后再调用就会成功，如支付宝到银行扣款也是类似需求。这里的重试需要可靠的重试，即失败重试的消息不因为Consumer宕机导致丢失。严格的消息顺序Kafka支持消息顺序，但是一台Broker宕机后，就会产生消息乱序RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，发送消息会失败，但是不会乱序Mysql Binlog分发需要严格的消息顺序定时消息Kafka不支持定时消息RocketMQ支持两类定时消息开源版本RocketMQ仅支持定时Level，定时Level用户可定制阿里云ONS支持定时Level，以及指定的毫秒级别的延时时间分布式事务消息Kafka不支持分布式事务消息阿里云ONS支持分布式定时消息，未来开源版本的RocketMQ也有计划支持分布式事务消息消息查询Kafka不支持消息查询RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息（发送消息时指定一个Message Key，任意字符串，例如指定为订单Id）总结：消息查询对于定位消息丢失问题非常有帮助，例如某个订单处理失败，是消息没收到还是收到处理出错了。消息回溯Kafka理论上可以按照Offset来回溯消息RocketMQ支持按照时间来回溯消息，精度毫秒，例如从一天之前的某时某分某秒开始重新消费消息总结：典型业务场景如consumer做订单分析，但是由于程序逻辑或者依赖的系统发生故障等原因，导致今天消费的消息全部无效，需要重新从昨天零点开始消费，那么以时间为起点的消息重放功能对于业务非常有帮助。消费并行度Kafka的消费并行度依赖Topic配置的分区数，如分区数为10，那么最多10台机器来并行消费（每台机器只能开启一个线程），或者一台机器消费（10个线程并行消费）。即消费并行度和分区数一致。RocketMQ消费并行度分两种情况顺序消费方式并行度同Kafka完全一致乱序方式并行度取决于Consumer的线程数，如Topic配置10个队列，10台机器消费，每台机器100个线程，那么并行度为1000。消息轨迹Kafka不支持消息轨迹阿里云ONS支持消息轨迹开发语言友好性Kafka采用Scala编写RocketMQ采用Java语言编写Broker端消息过滤Kafka不支持Broker端的消息过滤RocketMQ支持两种Broker端消息过滤方式根据Message Tag来过滤，相当于子topic概念向服务器上传一段Java代码，可以对消息做任意形式的过滤，甚至可以做Message Body的过滤拆分。消息堆积能力理论上Kafka要比RocketMQ的堆积能力更强，不过RocketMQ单机也可以支持亿级的消息堆积能力，我们认为这个堆积能力已经完全可以满足业务需求。开源社区活跃度Kafka社区更新较慢RocketMQ的github社区有250个个人、公司用户登记了联系方式，QQ群超过1000人。成熟度Kafka在日志领域比较成熟RocketMQ在阿里集团内部有大量的应用在使用，每天都产生海量的消息，并且顺利支持了多次天猫双十一海量消息考验，是数据削峰填谷的利器。

面试题 redis 都有哪些数据类型？分别在哪些场景下使用比较合适？ 面试官心理分析 除非是面试官感觉看你简历，是工作 3 年以内的比较初级的同学，可能对技术没有很深入的研究，面试官才会问这类问题。否则，在宝贵的面试时间里，面试官实在不想多问。 其实问这个问题，主要有两个原因： 看看你到底有没有全面的了解 redis 有哪些功能，一般怎么来用，啥场景用什么，就怕你别就会最简单的 KV 操作； 看看你在实际项目里都怎么玩儿过 redis。 要是你回答的不好，没说出几种数据类型，也没说什么场景，你完了，面试官对你印象肯定不好，觉得你平时就是做个简单的 set 和 get。 面试题剖析 redis 主要有以下几种数据类型： stringhashlistsetsorted set string 这是最简单的类型，就是普通的 set 和 get，做简单的 KV 缓存。 set college szu hash 这个是类似 map 的一种结构，这个一般就是可以将结构化的数据，比如一个对象（前提是这个对象没嵌套其他的对象）给缓存在 redis 里，然后每次读写缓存的时候，可以就操作 hash 里的某个字段。 hset person name bingo hset person age 20 hset person id 1 hget person name person = { "name": "bingo", "age": 20, "id": 1 } list list 是有序列表，这个可以玩儿出很多花样。 比如可以通过 list 存储一些列表型的数据结构，类似粉丝列表、文章的评论列表之类的东西。 比如可以通过 lrange 命令，读取某个闭区间内的元素，可以基于 list 实现分页查询，这个是很棒的一个功能，基于 redis 实现简单的高性能分页，可以做类似微博那种下拉不断分页的东西，性能高，就一页一页走。 0开始位置，-1结束位置，结束位置为-1时，表示列表的最后一个位置，即查看所有。 lrange mylist 0 -1 比如可以搞个简单的消息队列，从 list 头怼进去，从 list 尾巴那里弄出来。 lpush mylist 1 lpush mylist 2 lpush mylist 3 4 5 #1 rpop mylist set set 是无序集合，自动去重。 直接基于 set 将系统里需要去重的数据扔进去，自动就给去重了，如果你需要对一些数据进行快速的全局去重，你当然也可以基于 jvm 内存里的 HashSet 进行去重，但是如果你的某个系统部署在多台机器上呢？得基于 redis 进行全局的 set 去重。 可以基于 set 玩儿交集、并集、差集的操作，比如交集吧，可以把两个人的粉丝列表整一个交集，看看俩人的共同好友是谁？对吧。 把两个大 V 的粉丝都放在两个 set 中，对两个 set 做交集。 往期回顾： 【Java问答学堂】1期 为什么使用消息队列？消息队列有什么优点和缺点？Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？ 【Java问答学堂】2期 如何保证消息队列的高可用？ 【Java问答学堂】3期 如何保证消息不被重复消费？或者说，如何保证消息消费的幂等性？ 【Java问答学堂】4期 如何保证消息的可靠性传输？（如何处理消息丢失的问题？） 【Java问答学堂】5期 如何保证消息的顺序性？ 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题？ 【Java问答学堂】7期 如果让你写一个消息队列，该如何进行架构设计？ 【Java问答学堂】8期 es 的分布式架构原理能说一下么（es 是如何实现分布式的啊）？ 【Java问答学堂】9期 es 写入数据的工作原理是什么啊？es 查询数据的工作原理是什么啊？ 【Java问答学堂】10期 es 在数据量很大的情况下（数十亿级别）如何提高查询效率啊？ 【Java问答学堂】11期 es 生产集群的部署架构是什么？每个索引的数据量大概有多少？ 【Java问答学堂】12期 项目中缓存是如何使用的？为什么要用缓存？缓存使用不当会造成什么后果？ 【Java问答学堂】13期 redis 和 memcached 有什么区别？

大量使用rest/xml. 我这做的好多系统我都喜欢rest,清晰,明了. 量多就用XML.良好的结构不用你多说什么的. ######我赶脚还是webwervice 把,你只是隔离了B系统的信息,我不知道你这个隔离的意义是什么 如果是已经不想使用webservice了,你可以自己定义xml 自己返回定义好的xml就可以了 如果仅仅是数据需要封装下，我感觉你还是可以继续使用webservice######抽取的目标系统，赞定位X系统，X系统主要是为了和A系统（公司内部系统）使用新的通信方式，比如json,xml,等。B系统是外部平台，X系统需要从B系统接受大量的请求（千万级），为了方便统计和查询请求的业务信息，将X系统隔离出来。所以。。。###### xfire么？ ###### 提供三种参考： 1.SpringHttpInvoke 基于http协议 2.RMI 3.Socket                   ######HttpInvoke 大爱######同步用json 主要是同步，异步处理不同###### ESB么..