顺序点可以做什么

首先NoSQL包括了很多类型，不过就你在问题中提到的KVDB似乎并不完全适合你的应用场景，如果你硬要用也没什么不可以，只不过把简单的事情搞复杂了。单一的key-value型数据库，比较适用于索引输出加速（比如搜索结果的输出），随机数据多处复用（比如SNS消息发送，内容就存在缓存里，只需要发送id就行了），或者简单的数据共享（比如session信息，或者配置信息）等等。像你这种单点对单点的用KV型数据库并不能完全解决问题，因为它只能存储随机数据，数据之间没有顺序关系，所以你还得配合关系型数据库做索引，不过我建议你先完全用mysql实现一个版本，把流程走通，然后在按情况将存储换为更加强大的redis或者mongodb都可以。

1.第一个问题通过数据版本，也就是所谓的乐观锁解决。 2.先写日志log,然后ack机制。其实很多这种方式被很多应用所用到比如mysql。 3.用户注册本身这个功能不属于高频调用，所以性能上不需要考虑太多，直接悲观锁实现即可。而且这种可能性非常低，就算失败，那么返回给用户一个能理解的失败信息即可。######回复 @sixliu:谢谢回复靠谱的回答真不多我再等等看...######回复 @花歌:第二个可能没太理解你的场景######谢谢咯~1和3可以，我看看还有什么别的方案，差不多也就这么做了，2的话再考虑考虑吧感觉还是有点不适用场景###### 三个问题，其实就是同一个并发的问题，###### 都是并发中会出现的问题。 1说的在内存里的情况，就是2。 1说的在数据库中的情况，就是3。 在数据库中，数据库自己会有锁来解决这个问题，遇到这种情况会修改失败，程序中捕获这种异常做处理返回给前台就可以了。 在内存中，单机单进程单线程，会有顺序，因此没有问题。多机或多进程或多线程操作同一数据，会出现此问题。一种实现方式是加锁，相当于仿照数据库那样的实现，内存正在被修改时，其他的修改会被阻塞或者异常终止。另一种方式是通过队列实现顺序操作，所有的修改都发送到一个程序修改。######让我想想，嗯差不多，回答比较靠谱，谢了先其实...我用的是nodejs全异步操作，前面的数据库操作没完成，后面的也可以进入函数，如果网络延迟，就会造成执行完成顺序和开始执行顺序不一致...等等想一会再问你哈###### 1.是设计上的问题 两个操作如果有先后顺序 就得先后执行  一个操作完了之后再下一个操作 不可能明知道有一前一后却还要非得一起 2.这个就是非常典型的数据库事务 就是保证多个不相关的操作的原子性 只要其中一个出问题就全部回滚 不存在有的成功有的失败 事务还是个挺复杂的东西 mongodb都还不支持事务 多服务器之间分布式的事务也是有些麻烦的  3.同时的操作数据库自己会进行锁的处理 对数据库来说还是一前一后  如果某个字段设置了唯一索引 那后面的那个必然会出错 代码里正常处理就可以了 所以用户名不唯一的处理有两个地方 一个是在插入之前 一个是在插入时抛出唯一索引异常   当然也可以在新建用户这一整个操作上加锁 全局同时只能有一个用户在新建 不过这样可能效率不高 ######问题1现实情况就是这样用户以为他的操作有顺序但基于连接池算是并发操作即时不用池那也是异步操作不能保证顺序所以只能考虑数据库锁时间戳问题2还没到数据库呢...只考虑多个内存中的对象操作问题3现在就是这样处理的###### 1.加锁 2.加事务控制 3.异常捕获与处理 工作不满一年吧######不好意思...工作6年多了开发经验10多年问题1暂时用乐观锁解决了问题2事务控制个毛线问题你可能是没读清内存中的几个对象而已和数据库无关就是事务也得自己实现这话谁都会说我想听的是备忘录模式这种...到底怎么做能优雅点还是我从需求设计上可能有问题问题3靠数据库唯一约束出错返回太暴力现在就是这么做的也可以数据库加锁怕影响性能###### 1，updateusersetstatus=2wherestatus=3andid=1; 2，用户名设置唯一索引。###### 可以用现在拷贝上操作，再合并的方法解决。1、按顺序合并。2、按状态合并。3、按索引合并。

1.第一个问题通过数据版本，也就是所谓的乐观锁解决。 2.先写日志log,然后ack机制。其实很多这种方式被很多应用所用到比如mysql。 3.用户注册本身这个功能不属于高频调用，所以性能上不需要考虑太多，直接悲观锁实现即可。而且这种可能性非常低，就算失败，那么返回给用户一个能理解的失败信息即可。######回复 @sixliu : 谢谢回复 靠谱的回答真不多 我再等等看...######回复 @花歌 : 第二个 可能没太理解你的场景######谢谢咯~ 1和3可以，我看看还有什么别的方案，差不多也就这么做了，2的话 再考虑考虑吧 感觉还是有点不适用场景###### 三个问题，其实就是同一个并发的问题，###### 都是并发中会出现的问题。 1说的在内存里的情况，就是2。 1说的在数据库中的情况，就是3。 在数据库中，数据库自己会有锁来解决这个问题，遇到这种情况会修改失败，程序中捕获这种异常做处理返回给前台就可以了。 在内存中，单机单进程单线程，会有顺序，因此没有问题。多机或多进程或多线程操作同一数据，会出现此问题。一种实现方式是加锁，相当于仿照数据库那样的实现，内存正在被修改时，其他的修改会被阻塞或者异常终止。另一种方式是通过队列实现顺序操作，所有的修改都发送到一个程序修改。######让我想想，嗯 差不多，回答比较靠谱，谢了先 其实...我用的是nodejs 全异步操作，前面的数据库操作没完成，后面的也可以进入函数，如果网络延迟，就会造成执行完成顺序和开始执行顺序不一致... 等等想一会再问你哈###### 1. 是设计上的问题  两个操作如果有先后顺序  就得先后执行   一个操作完了之后再下一个操作   不可能明知道有一前一后 却还要非得一起 2. 这个就是非常典型的数据库事务   就是保证多个不相关的操作的原子性  只要其中一个出问题就全部回滚  不存在有的成功有的失败  事务还是个挺复杂的东西   mongodb都还不支持事务  多服务器之间分布式的事务也是有些麻烦的   3. 同时的操作 数据库自己会进行锁的处理  对数据库来说还是一前一后    如果某个字段设置了唯一索引  那后面的那个必然会出错  代码里正常处理就可以了   所以用户名不唯一的处理有两个地方  一个是在插入之前  一个是在插入时抛出唯一索引异常      当然也可以在新建用户这一整个操作上加锁   全局同时只能有一个用户在新建  不过这样可能效率不高  ######问题1 现实情况就是这样 用户以为他的操作有顺序 但基于连接池 算是并发操作 即时不用池 那也是异步操作 不能保证顺序 所以只能考虑数据库锁 时间戳 问题2 还没到数据库呢... 只考虑多个内存中的对象操作 问题3 现在就是这样处理的###### 1.加锁 2.加事务控制 3.异常捕获与处理 工作不满一年吧######不好意思... 工作6年多了 开发经验10多年 问题1 暂时用乐观锁解决了 问题2 事务控制个毛线 问题你可能是没读清 内存中的几个对象而已 和数据库无关 就是事务也得自己实现 这话谁都会说 我想听的是 备忘录模式 这种... 到底怎么做能优雅点 还是我从需求设计上可能有问题 问题3 靠数据库唯一约束出错返回太暴力 现在就是这么做的 也可以数据库加锁 怕影响性能###### 1，update user set status=2 where status=3 and id=1; 2，用户名设置唯一索引。###### 可以用现在拷贝上操作，再合并的方法解决。1、按顺序合并。2、按状态合并。3、按索引合并。

对于大学生求职者而言，一份完整的简历，应该包括以下几部分：求职职位、基本信息、教育背景、职业能力、在校经历、实习经历、荣誉奖励、自我评价以及科研经历、项目经历等几个板块。 具体每个板块应该包括什么内容呢?那就要看HR想要从这几部分获取的什么信息，给HR想看到他想看到的，HR才会给你想要的!第一、 HR需要知道你想做什么所以你要写明自己的求职职位，一般一份简历一个求职意向，或是2到3个相似相近的求职意向。第二、 HR需要知道你是谁所以你要写明自己的基本信息，包含姓名、性别、出生年月、联系方式、专业、学历、政治面貌等。第三、HR需要知道你学过些什么、学的这么样所以你要说明教育背景，包括高校、专业、主修课程以及考试成绩、学分绩点、排名情况第四、HR需要知道你能做什么所以你要说明自己职业能力。包括你取得了什么相关的证书、掌握了什么相关的实操能力等第五、 HR需要知道你曾经做过什么所以你要告诉hr你的在校经历和实习经历。并且建议你按照时间、单位、职位、工作内容、工作成果或收获的方式一一展现。特别强调，这部分是HR必然会关注的内容，所以一定要 紧紧围绕求职职位，按照一定的逻辑顺序，充分展现自己与求职职位的强烈的匹配性。第六、HR需要知道你获得了什么样的成绩或荣誉所以你要告诉HR你的荣誉奖励。一般建议按照奖励的含金量，如国家级奖励、省级奖励、校级奖励或者是按照和求职职位的相关度来排序，如果要按照时间排序，建议倒叙。第七、HR需要知道你是个什么样子的人所以你要在简历中包含自我评价部分，用于说明自己和职位相关的素质能力或者性格品质等等。在此处也可以说明自己对于求职企业和求职职位的渴望。

说一说我的一点看法：一、优惠策略有多种形式，但是无论哪种都是在所选购商品种类、数量以及订单金额上做文章，因此可以设计一个通用的过滤器Filter，它接受一个订单（账号、商品号、数量、单价、总价）作为输入，同时返回一个新的订单（账号、商品号、数量、单价、总价、优惠类型），每一个Filter都可以在内部定义一套优惠方案。二、优惠策略的组合方式有1.可叠加的（买二送一、满500打7折可以同时使用）2.选最有利的（满500减100和会员卡打7折不能同时使用，但是可以选择其中一个使得价格最低）3.互斥的（促销商品不能同时享受满减优惠）等多种情况。因此为Filter设计一套组合系统： 每一个Filter内部都可以由其他的Filter组合而成，并有如下几种方式：1.并联（选最大优惠/最小优惠）2.优先级（当多个优惠策略同时满足时，选优先级最高的）3.串联（可以同时使用）三、针对常见的优惠（如满减、满送、折扣等）做一套模板，可以随时使用参数进行实例化： 例如满减: OffAtFilterFactory(type, off, at)可以指定type类型商品满at的时候减去off，并产生一个相应的Filter以供使用。 每出现新的优惠，就手动画一画图，把优先级、串并联关系捋清，然后从最内层开始构造Filter，层层嵌套起来（想来也不会超过三层吧）。 之后做一套配置系统，使用XML也好JSON也好，可以直接把优惠写在配置文件里，Filter的生成、组合都由程序读取配置文件后自动进行。 最好的莫过于做一套图形化配置系统，可以通过拖模块画图的方式来写生成配置文件。实现的话，简单说一下吧，做到手动写Filter还是不难的，至于怎么根据配置文件生成代码，就需要较大篇幅这里就不提了。看你加了Java话题，我没正经用过Java，就只说一下伪代码哈哈：class Order {//存储订单的各项信息}//这个类要作为一个抽象类abstract class Filter {//构造函数什么的 //对订单o执行操作 abstract Order apply(Order o);}//这个类是最基础的，非组合式的Filter，也就是说它只能完成一个优惠策略class PrimitiveFilter extends Filter {boolean fit(Order o) { //返回o是否符合优惠条件 } Order apply(Order o) { //直接对o进行操作，获取订单信息，根据优惠策略生成对应的优惠后的订单并返回 }}class ParallelFilter extends Filter {Vector<Filter> pvf; //pvf按照优先级存储各个Filter Boolean fit(Order o) { //按照优先级（使用i从0到pvf.length迭代），判断订单o是否符合pvf[i]中的条件（使用fit方法），如果发现符合的，就返回true //都不符合返回false } Order apply(Order o) { //按照优先级（使用i从0到pvf.length迭代），判断订单o是否符合pvf[i]中的条件（使用fit方法），如果符合，即返回pvf[i].apply(o) //如果不符合，继续判断下一个Filter //如果所有的Filter都不符合，返回原订单 }}class SerialFilter extends Filter {Vector<Filter> svf; //按照串联顺序存储Filter（其实这个也没什么顺序可言） Boolean fit(Order o) { //svf中所有Filter都符合才返回true //有一个不符合就返回false } Order apply(Order o) { //按顺序把o通过所有的Filter //用Vector的reduce方法就好了，不知道Java里有没有 //没有的话： Order t = o; for (Filter f in svf) { t = f(t); } return t; }}上面这些就足够实现三种优惠组合方案啦。

面试题 如果让你写一个消息队列，该如何进行架构设计？说一下你的思路。 面试官心理分析 其实聊到这个问题，一般面试官要考察两块： 你有没有对某一个消息队列做过较为深入的原理的了解，或者从整体了解把握住一个消息队列的架构原理。 看看你的设计能力，给你一个常见的系统，就是消息队列系统，看看你能不能从全局把握一下整体架构设计，给出一些关键点出来。 说实话，问类似问题的时候，大部分人基本都会蒙，因为平时从来没有思考过类似的问题，大多数人就是平时埋头用，从来不去思考背后的一些东西。类似的问题，比如，如果让你来设计一个 Spring 框架你会怎么做？如果让你来设计一个 Dubbo 框架你会怎么做？如果让你来设计一个 MyBatis 框架你会怎么做？ 面试题剖析 其实回答这类问题，说白了，不求你看过那技术的源码，起码你要大概知道那个技术的基本原理、核心组成部分、基本架构构成，然后参照一些开源的技术把一个系统设计出来的思路说一下就好。 比如说这个消息队列系统，我们从以下几个角度来考虑一下： 首先这个 mq 得支持可伸缩性吧，就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么搞？设计个分布式的系统呗，参照一下 kafka 的设计理念，broker -> topic -> partition，每个 partition 放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给 topic 增加 partition，然后做数据迁移，增加机器，不就可以存放更多数据，提供更高的吞吐量了？ 其次你得考虑一下这个 mq 的数据要不要落地磁盘吧？那肯定要了，落磁盘才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊？顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，这就是 kafka 的思路。 其次你考虑一下你的 mq 的可用性啊？这个事儿，具体参考之前可用性那个环节讲解的 kafka 的高可用保障机制。多副本 -> leader & follower -> broker 挂了重新选举 leader 即可对外服务。 能不能支持数据 0 丢失啊？可以的，参考我们之前说的那个 kafka 数据零丢失方案。 mq 肯定是很复杂的，面试官问你这个问题，其实是个开放题，他就是看看你有没有从架构角度整体构思和设计的思维以及能力。确实这个问题可以刷掉一大批人，因为大部分人平时不思考这些东西。 往期回顾： 【Java问答学堂】1期 为什么使用消息队列？消息队列有什么优点和缺点？Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？ 【Java问答学堂】2期 如何保证消息队列的高可用？ 【Java问答学堂】3期 如何保证消息不被重复消费？或者说，如何保证消息消费的幂等性？ 【Java问答学堂】4期 如何保证消息的可靠性传输？（如何处理消息丢失的问题？） 【Java问答学堂】5期 如何保证消息的顺序性？ 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题？

您绝对应该花一些时间阅读索引，有关索引的文章很多，了解发生的事情很重要。 广义地说，索引对表的行强加了顺序。 为简单起见，假设表只是一个大CSV文件。每当插入一行时，它就会插入到末尾。因此，表的“自然”顺序就是插入行的顺序。 想象一下，您已经在非常基本的电子表格应用程序中加载了CSV文件。该电子表格所做的只是显示数据，并按顺序对行编号。 现在，假设您需要在第三列中找到所有具有“ M”值的行。给定可用的资源，您只有一个选择。您扫描表，检查每一行的第三列的值。如果您有很多行，此方法（“表扫描”）可能需要很长时间！ 现在想象一下，除了该表之外，您还具有索引。该特定索引是第三列中的值的索引。该索引以某种有意义的顺序（例如，按字母顺序）列出了第三列中的所有值，并为它们中的每一个提供了该值出现的行号列表。 现在，您有一个很好的策略来查找第三列的值为“ M”的所有行。例如，您可以执行二进制搜索！表扫描要求您查看N行（其中N是行数），而二进制搜索仅要求您查看log-n索引条目，在最坏的情况下。哇，这肯定容易得多！ 当然，如果您有此索引，并且要向表中添加行（最后，因为这是我们的概念表的工作方式），则需要每次都更新索引。因此，您在编写新行时需要做更多的工作，但是在搜索内容时可以节省大量时间。 因此，通常，索引在读取效率和写入效率之间产生了折衷。没有索引，插入会非常快-数据库引擎只会在表中添加一行。添加索引时，引擎必须在执行插入操作时更新每个索引。 另一方面，读取变得更快。 希望这能解决您的前两个问题（正如其他人回答的那样-您需要找到合适的平衡点）。 您的第三个场景更加复杂。如果您使用的是LIKE，则索引引擎通常可以帮助您将读取速度提高到第一个“％”。换句话说，如果您正在选择WHERE列，例如'foo％bar％'，则数据库将使用索引查找列以“ foo”开头的所有行，然后需要扫描该中间行集以找到子集包含“酒吧”。SELECT ... WHERE列之类的'％bar％'无法使用索引。我希望你能明白为什么。 最后，您需要开始考虑多个列上的索引。这个概念是相同的，并且行为类似于LIKE东西-本质上，如果在（a，b，c）上有索引，则引擎将尽最大可能继续使用从左到右的索引。因此，在列a上进行搜索可能会使用（a，b，c）索引，在（a，b）上也会使用索引。但是，如果您要搜索WHERE b = 5 AND c = 1），则引擎将需要进行全表扫描。 希望这可以帮助您有所了解，但是我必须重申，您最好花几个小时来深入研究能解释这些问题的好文章。阅读特定数据库服务器的文档也是一个好主意。查询计划者实现和使用索引的方式可以相差很大。 来源：stack overflow

索引索引是提高数据库表访问速度的方法。分为聚集索引和非聚集索引。聚集索引：对正文内容按照一定规则排序的目录。非聚集索引：目录按照一定的顺序排列，正文按照另一种顺序排列，目录与正文之间保持一种映射关系。把数据库索引比作字典查询索引，聚集索引就是按照拼音查找，拼音栏中字的顺序就是查找得到的字的顺序。非聚集索引就像按照偏旁部首查找，同是单人旁查到的字所在的页码可能是杂乱的，没有顺序的。存储结构内存中存储的数据是有限的，当需要在磁盘中进行查找时就涉及到了磁盘的 I/O 操作。当磁盘驱动器执行读/写功能时。盘片装在一个主轴上，并绕主轴高速旋转，当磁道在读/写头(又叫磁头) 下通过时，就可以进行数据的读 / 写了。磁盘读取数据是以盘块(block)为基本单位的。位于同一盘块中的所有数据都能被一次性全部读取出来。而磁盘IO代价主要花费在查找时间Ts上。因此我们应该尽量将相关信息存放在同一盘块，同一磁道中。或者至少放在同一柱面或相邻柱面上，以求在读/写信息时尽量减少磁头来回移动的次数，避免过多的查找时间。索引查找时产生磁盘I/O消耗，相对于内存存取，I/O存取的消耗要高几个数量级，所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的时间复杂度。树高度越小，I/O次数越少。平衡树的高度过深进行多次磁盘IO，导致查询效率低下，而B树和B+树树中每个结点最多含有m个孩子，所以相对平衡树B树和B+树的高度比较低。B树每个节点都存储key和data，所有节点组成这棵树，并且叶子节点指针为null。B+树只有叶子节点存储data，叶子节点包含了这棵树的所有键值，叶子节点不存储指针。所有非终端节点看成是索引，节点中仅含有其子树根节点最大（或最小）的关键字，不包含查找的有效信息。B+树中所有叶子节点都是通过指针连接在一起。总结：为什么使用B+树？1.文件很大，不可能全部存储在内存中，故要存储到磁盘上2.索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数（为什么使用B-/+Tree，还跟磁盘存取原理有关，具体看下边分析）局部性原理与磁盘预读，预读的长度一般为页（page）的整倍数，（在许多操作系统中，页得大小通常为4k）数据库系统巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样 每个节点只需要一次I/O 就可以完全载入，(由于节点中有两个数组，所以地址连续)。而红黑树这种结构， h 明显要深的多。由于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性。为什么B+树比B树更适合做索引？1.B+树磁盘读写代价更低B+的内部结点并没有指向关键字具体信息的指针，即内部节点不存储数据。因此其内部结点相对B 树更小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。2.B+-tree的查询效率更加稳定由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。在MySQL中，最常用的两个存储引擎是MyISAM和InnoDB，它们对索引的实现方式是不同的。MyISAM data存的是数据地址。索引是索引，数据是数据。InnoDB data存的是数据本身。索引也是数据。原文地址：https://blog.csdn.net/qq_40180411/article/details/81431386

如果你是一个个人。做个商城，只要有点效果就满足的。你只需要多交微信朋友。多让他们帮你发朋友圈就足够了 商城。打广告。开销是很大的。在做商城之前。就应该有好的策略。然后再开始做商城。我感觉你的顺序搞反了。 对于小商城。这类销售为主的网站。你最好的方式。不如直接上taobao开店。容易引来流量。自己开，不合适。 对于中等规模的商城。一般是服务某个行业或某个地区的。如果是服务某个行业的。你应该在同行里打广告或是找同行合作代理你的产品 如果你的商城是服务某个小范围的地区的。你应该找人。把宣传单。给大家送上门。贴到广告栏里去。 如果你是服务比较大的范围的商城。你也可以采用贴广告的方式。找很多兼职。他们帮你贴。贴好给你发个照片。你给他们红包。省钱也效果好 如果你是比较大的规模的商城。你的竞争对手就是taobao jd 等了。那还是建议你放弃吧。 对于比较大模式的商城。你的最好方式是电视广告、或 去上市（很多人都炒股。很快会认识你） 比较大规模的商城，最好的办法。还是多和实体商家合作。否则你没办法和taobao竞争。 不管你是什么规模的商城，口碑宣传都是必须的。也是效果最好的。你的推广费。应该重点花在这方面。 口碑宣传方式有很多种了。比如编故事。我见过一个商家。发帖子说。在他们店里，那个mm很漂亮。吸引了很多人去店里参观。 口碑的方式宣传。最好还是多提供点好的服务。比如产品特别优惠。足以吸引人。这样就会有人来了。其他产品卖贵点。把推广产品亏本销售。

http://docs.mongoing.com/manual-zh/tutorial/perform-two-phase-commits.html要么操作全都执行，要么都不执行，不能执行一半，改了几条数据了，看哎哟好像不对，那扔着吧。Consistency 在数据库领域的意思跟在分布式系统里的意思不一样，指数据的外部约束有没有满足，比如帐户之间转账，不能最后总和还是负数，或者超过原来的总和了。那文档中的办法是怎么做的呢？简单说，就是在执行操作之前，记下来要做什么，以后可以 redo。然后保证每个操作都是 幂等的 ，就是说重复执行也没事。比如，赋值是幂等的，但是加一个数就不是幂等的。利用 MongoDB 提供的单文档的原子性，使用一些辅助的数据做到幂等，最后把辅助的数据清除掉。如果你的操作本身就是幂等的，那就不需要辅助数据了。如果要 undo，也是可能的，那就要记下如何 undo。但是 ACID 中的 Isolation 是没有的，也就是说事务之间有交叉，别的并发操作可以看到中间不一致的状态，上面说的外部约束只能最终得到保证。比如说，事务 T1 包括 (张三：加100；李四：减100)，事务 T2 包括 (张三：加200；李四：减200)，如果不加以限制，可能的顺序是：1.T1 (张三：加100)2.T2 (张三：加200)3.T2 (李四：减200)4.T1 (李四：减100)T2 执行的时候可以读取并修改 T1 的中间结果，在转账这个问题上没有大问题，因为加减是 可交换 的操作，先后不影响最终结果。但是如果我们把事务改成 T1 (张三 ＝ 100；李四 ＝ 100)和T2 (张三 ＝ 200；李四 ＝ 200) 这样最终的结果就可能是 (张三 ＝ 200；李四 ＝ 100)，有可能就不满足一致性了。但是如果能在应用里保证顺序地执行这两个事务，问题就避免了。大家也了解 Isolation 有几个级别，还有多版本等更复杂的。传统数据库在单机上也会在更强的 Isolation 和性能之间做权衡，提供不同的级别可选。这一点在分布式系统中被称作 Consistency，实现起来的代价就更高了，所以 MongoDB 不支持。不过对大多应用，这并不是太大的问题：1.可能异常情况在逻辑上也是可以接受的，比如微信群发，每个人收到的顺序并不一样。2.可能逻辑上并发就是不可能的，比如一个用户只能修改自己的数据，比如只有一个线程写数据。3.或者把需要的数据放到一个文档里，对单文档，MongoDB 保证原子性，别的操作也不可能看到文档一半被改了。4.或者可以在应用上层发现并解决。比如支付宝转账就自己实现了一套一致性协议，1分钟之内可以保证这一笔数据一致了。对你的要求，如果可以通过修改数据模型，让改动在一个文档里就方便了。最好是看看你具体的需要和应用的假设，分析分析可能出现的异常情况，最后想办法。还有一个办法，贵司可以购买 MongoDB 的支持服务，针对你现在的产品阶段和需求 (开发，维护，咨询，培训)，提供不同类型的专业级支持，比再请个程序员 / DevOp / DBA 便宜靠谱多了。

首先，这种模式可以让每个数据集都能为多订阅者所用。每个流处理过程的输入对任何需要的处理器都可用；同时每个输出也都对任何需要的都可用。这一点不仅对生产数据流很好用，而且也在复杂的数据处理管道里调试和监控阶段很有帮助。能快速的进入一个输出流并检查它的有效性，同时计算一些监控的统计数据，或者仅仅只是看看数据长什么样，这些都使得开发变的非常有可追踪性。 其次，这样使用日志能确保每个数据消费者处理过程中顺序可以被保留。某些事件数据可能被按时间戳松散地排序了，但是不是每种事件数据都这样。考虑从来自数据库的一个更新流，我们可能有一系列的流处理任务来处理这些数据并准备为搜索索引来做索引。如果对同一个记录同时做两次更新，那么我们最后可能在索引的最终结果出错。

" 用了两年的时间，终于把这个问题解决了。。######能分享下如何解决的吗###### 分布式事务的基本理论，2PC, QUORUM, PAXOS，系统要达到100w/s的水准靠水平分割 ######好问题，。。。######mark######你的解法是正确可行的，不知道面试官是怎么想的，估计面试官自己都没有答案。 消息队列是可以集群的，最终的瓶颈只是在数据库上面，所以要做多master应该就可以解决了。 如果单库多master还无法解决的话，那就要进行数据库分割。 如果分割了还无法解决的话，那就要采用内存数据库，然后在持久化到磁盘。 灵活运用吧。 ###### 两阶段提交本身属于强一致性模型，你又说做最终一致检查，有点概念不清的嫌疑。 所以面试官在听到你说2PC的时候，估计已经不想跟你扯了， 猜测~~。    其实海量分布式事务的解决方案就是最终一致性模型。 ######因为他的说法中有错别字，我没有看到2pc，这一点他的强一致模型确实和最终一致模型概念不清。楼主本身估计不是做架构的，是根据自己公司原来的架构体系自己总结的一些东西。不过楼主的解决方案的大体方向是可行的。###### 引用来自“jobet”的评论你的解法是正确可行的，不知道面试官是怎么想的，估计面试官自己都没有答案。 消息队列是可以集群的，最终的瓶颈只是在数据库上面，所以要做多master应该就可以解决了。 如果单库多master还无法解决的话，那就要进行数据库分割。 如果分割了还无法解决的话，那就要采用内存数据库，然后在持久化到磁盘。 灵活运用吧。 什么东西一大了，单纯靠数据库，分布式平台等数据工具是解决不了的。一定要结合具体业务特性，大概率下数据分布特征来做模型的重新设计和优化。这就是我说的，大数据的工作，hadoop之类的工具，并不能帮你做什么。还是自身业务模型设计的问题。哈######其实这个问题基本上没有正确的方案，每一个平台根据业务性质都会不同，唯一能够提供的就是一个大体的思虑，其他的根据自己的业务性质自行提炼和优化。###### 引用来自“兮风古道”的评论 两阶段提交本身属于强一致性模型，你又说做最终一致检查，有点概念不清的嫌疑。 所以面试官在听到你说2PC的时候，估计已经不想跟你扯了， 猜测~~。    其实海量分布式事务的解决方案就是最终一致性模型。 二段提交的时候，最后一次commit还是会出错的。。######回复 @jobet : 收到。。我搞错了。。######回复 @Brin想写程序 : 2pc是针对于多数据源的事务处理，也就是分布式事务。你说的这个不是。######回复 @jobet : 问一下mysql的autocommit=false后的，commit和rollback难道不是二段提交的吗？这个应该就是数据库的二段提交吧？######2pc的话，对性能的消耗是很大的。估计面试官是因为听到他说2pc就直接否决了，后续的已经没有兴趣了。###### Brin有什么好办法了，记得 博客里补上######我的解决方案是根据用户顺序处理，也就是用顺序一致性替代绝对一致性，然后用分布式消息队列，用一致性哈希算法，只将一个用户的数据发送给同一个处理者，然后按顺序执行这一个人的操作。所以这个是无锁的，可并行的。###### 引用来自“jobet”的评论你的解法是正确可行的，不知道面试官是怎么想的，估计面试官自己都没有答案。 消息队列是可以集群的，最终的瓶颈只是在数据库上面，所以要做多master应该就可以解决了。 如果单库多master还无法解决的话，那就要进行数据库分割。 如果分割了还无法解决的话，那就要采用内存数据库，然后在持久化到磁盘。 灵活运用吧。 引用来自“中山野鬼”的评论什么东西一大了，单纯靠数据库，分布式平台等数据工具是解决不了的。一定要结合具体业务特性，大概率下数据分布特征来做模型的重新设计和优化。这就是我说的，大数据的工作，hadoop之类的工具，并不能帮你做什么。还是自身业务模型设计的问题。哈 我也觉得是具体业务具体分析，比如在电商平台里面，在怎么分布式，买东西这个过程是一个用户触发的。 所以按照用户对纬度，对资源进行水平分割，应该可以解决大部分问题。 但是但是，最麻烦的是先有很多电商平台非常庞大，而且一开始就没有做这种分割，业务是一团乱麻，没人清楚这个用户的购买行为会影响多少台服务器里面的数据，所以只能寻找比较通用的解决方案。 也就是在某个层面上能彻底解决，现在好像思路还是从rpc层面去解决这个问题。找到统一的一劳永逸的中间价或者说体系结构。。 所以我也很难想明白。。######马克，学习了"

硬盘读写速度现在怎么都达不到千兆， ssd读也达不到。（特殊设备除外，貌似看到新闻说有实验室的产品读写速度可以过G） 不过可以采取，写入缓冲的方式，数据先保存在内存，再写入到硬盘，不过缺点怕掉电。 读的话，采取分布式的读，可以达到很高的吞吐量。 网络传输的话，问题在于怎么保证传输稳定和不出错######这对内存的要求很高啊，而且还不能耽误其他程序对内存的使用，这个内存我觉得应该很大吧###### 引用来自“十一文”的答案 硬盘读写速度现在怎么都达不到千兆， ssd读也达不到。（特殊设备除外，貌似看到新闻说有实验室的产品读写速度可以过G） 不过可以采取，写入缓冲的方式，数据先保存在内存，再写入到硬盘，不过缺点怕掉电。 读的话，采取分布式的读，可以达到很高的吞吐量。 网络传输的话，问题在于怎么保证传输稳定和不出错 这么说来， 在顺序存取方面 ， 网络传输速度相对与硬盘 io 速度还是有优势的，不知道这么理解是否成立。 因为机放内部设备间千兆网卡很常见，传输速度相当快，并且成本相对硬盘少许多。 ######看贴不跟帖，帖子要沉了。需要顶。 无论对错。发表点个人观点也好。不能让它沉。 ###### "千兆网卡很常见", 這裡 “ 千兆” 是指1000M bits, 大概也就100M Bytes。 Intel SSD 520 Sequential Read 已经可高达550M Bytes per second, 顺序写可高达275M Bytes per second.######回复 @十一文 : 现在的HBA卡4G的已经很通用了，好像12G的都出来了，一般服务器都有好几个接口的，再来个负载均很啥的，网络传输不是问题######汗 查了哈 还真是这样。擦我out了！######网络允许帮定双网卡。所以，网络传输可以更快点，相对来说，速度提升技术性难度小点。 磁盘阵列是否回更好？ 光线通讯用的网卡是否会更快点。 ###### 顺便提点应用。 是这样的， 排序在信息处理方面很常见。 无论用什么算法。都是在一个相对平等的环境中。 现实中应用，比如1g内容的排序和1T内容排序难点还是数据交换上。 1g可以全部加载进内存玩。1T就要涉及到信息交换了。如果一个系统界面，把存储信息部分扩展到近乎无限空间大小。 就好比内存数据交换比磁盘数据交换要快许多。 比如1T大小数据做排序。 只要一个设备顺序读取数据，按照开头部分把数据通过网络分发给N 台机器，处理除了开头部分数据，后面的数据排序。这样就可以N多设备协同工作。效率达到 1+1 > 2 的目的。 否则如果是1台设备需要 加载数据，排序， 临时存储， 加载另外数据，处理，临时存储，加载.... 汇总分结果，获得总结果。 1台设备这么处理，做了很多重复劳动。如果网络够快 多台设备 避免了重复加载。 达到 1+1>2######回复 @十一文 : 差不多的意思。######hadoop是把数据分成分成多个部分，每部分各自处理结果，然后汇总处理。即把你的1t的数据分成n份，然后每份分发给不同机器处理。然后汇总结果。不知道适用你的场景不？######貌似这中数据分析，现在流行用hadoop。楼主可以调研哈######这么说不好理解。形象一点说一下：假设有1000个数据样本，每个样本里有1T条数据内容。 一知每个样本内数据条目重复率为0.001%.目的，找出这1000个样本内，每个样本中重复的样本。并统计所有样本中重复的次数。 这个如果算复杂运算，不如说是大数据处理。 假设 每个设备 一次能加载1G条数据。######硬盘技术感觉好多年都在原地踏步没有质的飞跃啊###### @johnzhang68 毕竟转速有影响######磁性硬盘在容量方面还是有明显的飞跃。速度方面提高得慢一些。######或许未来，存储虚拟化是条路子。  数据处理和数据交互关系密切。 以数据处理为目的，建立多系统群集方式在处理上或许会比高计算系统群集更有优势。 ######又没落了。顶起 ######没有试过，关注一下######再看了哈貌似你真的很需要hadoop

MAS至少有API和直接写数据库两种方法的。貌似里面的MySQL是4.1以下，这个比较郁闷。 ######你看下我下面的回答######我刚进这个公司，也没人带我这个新人，MAS的相关开发API和文档我已经拿到了，然后呢公司里，有一个OA办公的系统，就是我们平时上班和办公用的，上面可以发送短信的，公司的内部人员之间，也可以跟外部的人发，不过用的是短信猫，现在业务量大了，短信猫承受不了，所以觉得用移动的MAS机，让我开发一个平台，因为公司的OA是可以任意嵌入一个新的功能什么的，我也不知道怎么做汗 序号模块名称项目描述1系统登录　　用户登录验证用户登录验证(密码由管理员分配)　　　2用户管理　　用户基本信息1、显示公司人员基本信息、进行部门分组、部门内部分组显示方式　权限配置1、管理员赋予OA通讯录人员发短信权限。　　2、系统目前分管理员、可发短信人员、可查看统计分析报表三种用户权限。　　　3收发短信　　收发短信1、支持可以指定OA通讯录的人员发送短信，包含群发。　　2、支持可以手动输入外部联系人号码发送短信，支持群发。　　3、支持接收短信功能。　　4、支持设置短信定时发送功能，实现定时发送设置好的短信。　　5、支持管理员配置通讯录分组，方便不同部门发送短信。　　6、支持OA实现业务功能，通过此系统实现短信提醒。　　　4统计分析　短信查询可根据时间、发短信人员、收短信人员模糊查询相应的短信内容记录　短信统计可以统计某个时间段的短信数量、各部门、个人的发送短信量　　　5对外接口　　对外接口提供标准的外部接口（（DB接口、API接口、webservice接口））　　　6需求调研需求调研　　　7系统设计系统设计　　　8测试测试　　　9实施实施　　　合计　　 这是需求，貌似还是我整理的。。。。。无语了，求一点点思路。。。######求什么思路啊？MAS就是一个工具而已，你针对它API做开发，应该按照你们的需求去做吧？ 使用MAS的顺序一般是这样的： 1、权限验证（对比MAS后台设置的用户密码及权限） 2、发送短信 或 接收短信 或 查看发送状态 然后，然后就没了。MAS只不过是你这个短信模块的一个外部小工具而已。######回复 @柳天俊 : 怎么写，看文档。我做的是直接写数据库的。######那JAVA发送短信是怎么回事，是我写意个类调用MAS的接口，还是调用什么方法的，这个具体又要怎么写啊######mas就是手机 api就是你的手指######不明白。。######别着急，有方法的，用户管理、统计分析那块应该是自己做，后面收发短信应该是调用API。对外接口这个，也就是使用WebService。######前面的就是给我一个公司的的员工通讯录的数据，我把它提取出来了，也实现了分组啊什么的，后面那个什么赋予权限的，我一点思路都没有，在后面的我问公司的现在MAS机还没下来，具体怎么做还不晓得，我以前从来没坐过什么的，刚毕业出来，那人就叫我说你搭个架子做吧。。。汗。。。我都不晓得做什么东西，。。。。######MAS机？华为的还是嘉讯的？中兴的？在机器的箱子里有个光盘，里面有API和Demo，把mas先配置好，使用mas里的软件看能不能发短信，然后调用API发短信。。。######是上海一个什么若雅的 现在MAS机还没拿到手 公司 就给了份文档######权限管理别人做好的模板，你照着用就行了，不知道就Google吧######还真没做好的模板，我百度看看吧，不知道能否搜到模板啊######帮你项一下 。 ######之前在国内一家OA厂商就职时，做过类似这种东西，短信猫，华为短信机，短信易都做过，原理都一样，看清楚API，初始化，连接，发送，断开，就这么个过程！没有什么深奥的！看文档，不行就看例程！######你换来换去换的还是卡发，你公司怎么没有想过换换网关的，MAS还需要自己的机器和程序员，成本很高，可以试试网关的

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

先补充一下概念：Java 内存模型中的可见性、原子性和有序性。可见性：　　可见性是一种复杂的属性，因为可见性中的错误总是会违背我们的直觉。通常，我们无法确保执行读操作的线程能适时地看到其他线程写入的值，有时甚至是根本不可能的事情。为了确保多个线程之间对内存写入操作的可见性，必须使用同步机制。　　可见性，是指线程之间的可见性，一个线程修改的状态对另一个线程是可见的。也就是一个线程修改的结果。另一个线程马上就能看到。比如：用volatile修饰的变量，就会具有可见性。volatile修饰的变量不允许线程内部缓存和重排序，即直接修改内存。所以对其他线程是可见的。但是这里需要注意一个问题，volatile只能让被他修饰内容具有可见性，但不能保证它具有原子性。比如 volatile int a = 0；之后有一个操作 a++；这个变量a具有可见性，但是a++ 依然是一个非原子操作，也就是这个操作同样存在线程安全问题。　　在 Java 中 volatile、synchronized 和 final 实现可见性。原子性：　　原子是世界上的最小单位，具有不可分割性。比如 a=0；（a非long和double类型） 这个操作是不可分割的，那么我们说这个操作时原子操作。再比如：a++； 这个操作实际是a = a + 1；是可分割的，所以他不是一个原子操作。非原子操作都会存在线程安全问题，需要我们使用同步技术（sychronized）来让它变成一个原子操作。一个操作是原子操作，那么我们称它具有原子性。java的concurrent包下提供了一些原子类，我们可以通过阅读API来了解这些原子类的用法。比如：AtomicInteger、AtomicLong、AtomicReference等。　　在 Java 中 synchronized 和在 lock、unlock 中操作保证原子性。有序性：　　Java 语言提供了 volatile 和 synchronized 两个关键字来保证线程之间操作的有序性，volatile 是因为其本身包含“禁止指令重排序”的语义，synchronized 是由“一个变量在同一个时刻只允许一条线程对其进行 lock 操作”这条规则获得的，此规则决定了持有同一个对象锁的两个同步块只能串行执行。下面内容摘录自《Java Concurrency in Practice》：　　下面一段代码在多线程环境下，将存在问题。复制代码+ View code1 /** 2 * @author zhengbinMac 3 */ 4 public class NoVisibility { 5 private static boolean ready; 6 private static int number; 7 private static class ReaderThread extends Thread { 8 @Override 9 public void run() {10 while(!ready) {11 Thread.yield();12 }13 System.out.println(number);14 }15 }16 public static void main(String[] args) {17 new ReaderThread().start();18 number = 42;19 ready = true;20 }21 }复制代码　　NoVisibility可能会持续循环下去，因为读线程可能永远都看不到ready的值。甚至NoVisibility可能会输出0，因为读线程可能看到了写入ready的值，但却没有看到之后写入number的值，这种现象被称为“重排序”。只要在某个线程中无法检测到重排序情况（即使在其他线程中可以明显地看到该线程中的重排序），那么就无法确保线程中的操作将按照程序中指定的顺序来执行。当主线程首先写入number，然后在没有同步的情况下写入ready，那么读线程看到的顺序可能与写入的顺序完全相反。　　在没有同步的情况下，编译器、处理器以及运行时等都可能对操作的执行顺序进行一些意想不到的调整。在缺乏足够同步的多线程程序中，要想对内存操作的执行春旭进行判断，无法得到正确的结论。　　这个看上去像是一个失败的设计，但却能使JVM充分地利用现代多核处理器的强大性能。例如，在缺少同步的情况下，Java内存模型允许编译器对操作顺序进行重排序，并将数值缓存在寄存器中。此外，它还允许CPU对操作顺序进行重排序，并将数值缓存在处理器特定的缓存中。二、Volatile原理　　Java语言提供了一种稍弱的同步机制，即volatile变量，用来确保将变量的更新操作通知到其他线程。当把变量声明为volatile类型后，编译器与运行时都会注意到这个变量是共享的，因此不会将该变量上的操作与其他内存操作一起重排序。volatile变量不会被缓存在寄存器或者对其他处理器不可见的地方，因此在读取volatile类型的变量时总会返回最新写入的值。　　在访问volatile变量时不会执行加锁操作，因此也就不会使执行线程阻塞，因此volatile变量是一种比sychronized关键字更轻量级的同步机制。　　当对非 volatile 变量进行读写的时候，每个线程先从内存拷贝变量到CPU缓存中。如果计算机有多个CPU，每个线程可能在不同的CPU上被处理，这意味着每个线程可以拷贝到不同的 CPU cache 中。　　而声明变量是 volatile 的，JVM 保证了每次读变量都从内存中读，跳过 CPU cache 这一步。当一个变量定义为 volatile 之后，将具备两种特性：　　1.保证此变量对所有的线程的可见性，这里的“可见性”，如本文开头所述，当一个线程修改了这个变量的值，volatile 保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。但普通变量做不到这点，普通变量的值在线程间传递均需要通过主内存（详见：Java内存模型）来完成。　　2.禁止指令重排序优化。有volatile修饰的变量，赋值后多执行了一个“load addl $0x0, (%esp)”操作，这个操作相当于一个内存屏障（指令重排序时不能把后面的指令重排序到内存屏障之前的位置），只有一个CPU访问内存时，并不需要内存屏障；（什么是指令重排序：是指CPU采用了允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理）。volatile 性能：　　volatile 的读性能消耗与普通变量几乎相同，但是写操作稍慢，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。

做出来就好，不考虑优雅的方案 **有个词叫做最佳实践，其实编码规范和最佳实践，是编程功底的重要体现。**优雅方案可以认为是最佳实践的升级版，它和上面说到的不断的重构是相辅相成的。不好的方案是什么呢？硬编码居多，没有可扩展性，用很丑陋的方式完成了功能。比如轮子是正方形的，也认为车子能开就行： 上次他们去做了一个关于试听课的方案，一个人能试听多少节课，正常的逻辑应该是在用户的表里加一个字段来表示。需求是写着邀请几个人，可以试听多少节课，所以他们判断试听多少节课就直接在通过邀请人的表里查询去做。完全没考虑到以后如果我变换了试听课的判断条件怎么办？实际上这是应该拆解成两部分，一个是试听课的产生条件，这是一个独立的模块，加一个是试听课的确认。像这种例子太多了，也和不做方案，不考虑扩展性有关系。就是接下来要说的。 不考虑未来需求的变化 工程师的水准，其实可以分成以下几个阶段： 1、面向功能编程 2、面向性能编程 3、面向未来编程 工程师拿到需求的第一件事，应该聚集在以下几个问题： 第一 、哪些需求是我之前完成过的 第二 、哪些需求是有可能变化的 第三 、有几种方案，分别支持什么样的需求变化 当一个新续期来时，往往都要推到重新来： 但是差一点的程序员就考虑不到那么远，一个是对业务不熟悉，判断不出来哪些需求可能会产生变化，一个是对可选的方案掌握的不多，根本就没有什么可选的余地，还有就是没有这种思维习惯，分不清楚哪些是现在要完成的，哪些是未来可能会支持或者是变动的。 遇到问题的时候不会试错 这也是新手常见的问题。很多时候新人会遇到问题，解决不了，去找一个有经验的工程师，这个有经验的工程师呢，大概也未曾遇到这种情况，但是他解决问题的思路清楚啊。一会儿试试这个，一会儿删删那段代码，很快就跑通了。解决问题是一个很见功底的技术点，而且是有很多方法论的，之前总结过一些，简单列举过来： 1.寻找正确的代码 2.理清楚正确的执行顺序 3.重现错误 4.最小化错误产生的场景 5.修改代码到一个已知的错误类型等等等。 解决问题就是一个分析推理的过程，而在这里呢，背后的功底就是你知道很多哪些是肯定不会错的小公理，然后再挨个去定位可能产生错误的环节，分解流程是最基础的工作。高级开发调试问题，往往如下：

危险的做法，因为gets是不做边界检查的，能运行可能是越界少运气好。新的C标准已经废弃了这个函数gets()函数是遇到回车键结束的，所以即便你有定义好chara[8]l了也是没用的。为什么学c语言，都喜欢折腾这些通过stdin给入的数据，怎么就不喜欢从文件中读取块后做分析？为了交互？c语言有多少机会写gets,scanf？而且是一个个从键盘里面折腾。至于catxxx|bin这种，块读取,fread指定长度，仍然是高效和逻辑清晰的。fwrite难不难我不知道，反正scanf很简单，输入一个int一行就够。我整个程序就输入一个int，用到毛cmplex。为啥不在程序中改？不用重新编译，而且我就想交互。scanf是歪门邪道的话，世界上所有的语言都包括这个歪门邪道。有一大批人，计算机和非计算机的，学语言就是为了混论文和泡妞，别老拿自己的角度看别人。 @小郭一号新手？我现在还在带新手，fread，fwrite很难吗？没关系，我甚至给出接口，而让他学习lex的使用，做文本词汇解析，有必要知道接口吗？交互，cmp文本对比，有必要肉眼一个个判断吗？这和基础没关系，和自己的目标有关系，学点歪门邪道有屁用，学语言不是为了工程难道是为了混论文，泡妞？回复 @中山野鬼:首先谢谢你们无私的解答，我确实是一个新手，刚上大二，目前只学了C语言，这学期学校正在教授数据结构，可是我对自己的未来还是比较迷茫的，没有目标，不知道正确的努力方向，和正确的学习策略：学什么，如何学等问题。请问您我到底该如何学习，学什么，顺序又是怎么样的？如何才能成为一个真正的大神呢？回复 @小郭一号:首先谢谢你们无私的解答，我确实是一个新手，刚上大二，目前只学了C语言，这学期学校正在教授数据结构，可是我对自己的未来还是比较迷茫的，没有目标，不知道正确的努力方向，和正确的学习策略：学什么，如何学等问题。请问您我到底该如何学习，学什么，顺序又是怎么样的？如何才能成为一个真正的大神呢？回复 @中山野鬼:谈体验要有个对照。新手自己写的程序，如果没有scanf交互，跟有scanf比较，明显后者体验要好。然而输入字符的体验不如鼠标，这就是新手总想写图形界面的原因。别老拿自己的角度看别人。那要看你栈分配了多少哈，输入的东西破坏了栈会崩掉哈 首先，编译器不会报错，因为你运行之前编译器根本不知道你输入啥，你想正常输入他也报错吗？这个属于运行时问题。其次，可以为了交互而使用键盘输入，但是不要折腾，针对这个问题野鬼喷的有一定道理。最后，你这个问题分为gets和栈内存两个部分，本人能力有限无法解释清。

DK8从2019年1月开始就要收费了，怎么办呢?其实这个问题本身就是有问题的，因为收费的并不是JDK8 , 而是JDK8后续的update (更新) 。什么是update? 如果你下载过JDK， 就会看到那些8u191, 8u192这样的东西，191,192就是update 的编号。这些update中通常会包含对JDK bug的fix ，或者一些功能的改变，增强， 拿update 172为例：这个update 修改了下面两个方法的文档，让文档描述和方法的实现一致：java.awt.Toolkit.getImage(URL u)java.awt.Toolkit.createimage(URL u)增加了在Windows8 及以上版中，对Swing/AWT 文本组件自动显示触摸键盘的功能36个Bug Fix假设JDK 8u192是2018年的最后一个update , 你下载并且安装了，那可以继续免费使用下去，没有任何问题。但是从2019年1月开始，如果你还想获取JDK的update , 对不起，你需要付费订阅。这个订阅服务的价格是这样的：对于PC， 每用户每月是2.5美元，对于服务器/云部署，每个processor 每月是25美元， 当然，数量多的话可以打折。Oracle 为什么要这么干呢?我推测有两个原因， 第一个原因可以理解： Oracle JDK8 2014年3月发布， 到2019年1月正式进入“End of Public Updates”， 这个版本Oracle支持了将近5年时间，一个版本的软件不可能无限期地支持下去，那样维护成本太高。第二个原因可能是没有多少人购买它的Java SE Advanced, Java SE Advanced Desktop 或者Java SE Suite， 这三个家伙是什么东西? 我们稍后解释。你也许注意到了， 我刚才再说JDK的时候，特别加上了Oracle 这个词，这是因为Java虚拟机的规范是开放的，任何人都可以去实现。老刘在2017年编程提高群第一季中，不就和大家一起实现了一个极为简单的版本吗? 当然那不能称为JVM ，只实现了对Class文件的解析，和一个能实现顺序，分支，循环，多态的简单执行引擎。其实现在的JDK提供者非常多，不像微软的.NET，独此一家，别无分号。Open JDK这个不多说，免费的开源实现，以GPL License发布，很多Linux发行版中都会包含这个Open JDK 。参与开发的大佬们有Oracle, RedHat (已被IBM收购)， Azul System, IBM , Apple , SAP。Oracle JDK就是我们常说的Java JDK ， 也是最常用的一个，是Oracle公司(收购了开发Java的Sun公司)对Java SE的实现。如果更详细分的话，可以分为Oracle JDK和 Oracle JRE。比如你想玩Minecraft 这样需要Java的游戏， 那只需要从java.com下载一个JRE就够了。如果你想基于Java做开发，那就需要从Oracle Technology Network(OTN)网站上下载JDK了。其他公司提供的JDK有实力的大公司，都有可能开发自己的JDK ， 比如IBM ，肯定要为自家的操作系统AIX，还有z/OS开发SDK。我在IBM工作的时候，根本就没有用过Oracle JDK，公司也不让用啊。HP，SAP也有自己的JDK , 可以为自己的硬件和软件做定制。Oracle Java SE Advanced, Java SE Advanced Desktop, Java SE Suite这名字老长了，也有点费解，简单来说，这是个收费的服务， 是Oracle 为企业级用户提供的高级工具和功能，可以监控、部署、管理企业级的Java程序，与此同时，你还可以下载那些老版本的JDK及其update。换句话说，如果你购买了这个服务，自然就不用担心什么JDK update 收费的问题。但是问题在于，到底有多少公司再使用这个服务? 如果你的公司在使用，欢迎告知。所以我猜测Oracle耍了一点小手段， 以后不要这个收费的服务了，把这些高级的功能加上JDK update 打包，统一成一个新的服务，就是之前说的订阅服务。总结一下如果你的公司已经买了这个Java SE Advanced (或者 Advanced Desktop), Java SE Suite的License, 什么都不用担心，你很安全。如果你的公司正在使用Oracle JDK 8 并且还想在2019年1月之后获得那些更新和支持，你需要购买Orace 的订阅服务。如果你的公司一直在在升级你的Oracle JDK ，比如说已经升级到JDK9了，你什么服务都不用购买， 因为那个订阅服务主要解决的是老版本的Update 的问题。或者可以选择一个没有public update的Oracle JDK ， 这也很常见，很多JDK已经非常稳定了， 比如Oracle JDK 7 发布日期是2011年7月， “End of Public Updates” 是2015年4月， 我估计现在还有不少公司还在使用JDK7这个已经没有public update的版本吧!如果真的出现了巨大的安全漏洞，你又没法升级JDK ，那只好去购买订阅服务去Fix了。当然，你的公司也可以选择纯开源OpenJDK。注意，我这里说的都是公司，都是商业用途，如果只是个人学习Java的话，没什么影响!

真正的问题不在于“怎么赋给外面用”，而是“何时外面才能用”。为了理解这一点，你得明白什么是 async programming（异步编程），看这个虚构例子： var outside // 0. 我在外面 $.getJSON('/some/api/endpoint', function(response) { outside = response // 1. 你当然可以把响应数据赋值给外面的代码 }) console.log(outside) // 2. 但是你没法保证接下来的代码能正确运行 // 因为以上代码的运行顺序是 0 -> 2 -> 1从 0 到 2，代码是自上而下同步运行的，然而 1（注意：1 是 $.getJSON 的回调函数而不是 $.getJSON 方法本身）是在之后运行的，并且确切的时间无法预知，它取决于对于 '/some/api/endpoint' 的请求何时返回。所以上面的虚拟例子从语法上来说没有任何问题，你只是无法保证它能运行出期望的结果罢了（在现实中由于 event loop 的机制，1 总是晚于 2 运行的）。 So，我们不知道何时异步回调会执行（只知道它晚于同步代码），那我们怎么办？幸运的是我们知道：“反正它会运行的”（除非请求失败，然而那属于错误处理或异常处理的部分，此处我们只谈 happy path），所以我们就告诉它：“当它运行时该做什么”就是了。所以之前的例子可以改写一下： var outside $.getJSON('/some/api/endpoint', function(response) { outside = response // 你还是可以把响应数据赋值给外面的代码 console.log(outside) // 然后再执行相应的逻辑，因为这里面是同步的，你能保证顺序 }) 当然这个例子太简单了，以至于 outside 这个变量根本就是个摆设（who cares），领会精神就好。当然在实际中，由于代码组织的关系，我们不总是能把逻辑上的顺序按照线性的方式自上而下的写代码，不过没关系只要你心中始终拎清楚现在正在写的代码将在何时运行就好。举例而言，稍微改动一下上面的例子： var outside // 我不知道什么时候，但终将在某一时刻我要打印出 outside 的值 // 至于这个值是什么就看到时候是谁传 response 进来了 // 注意：这也同时暗示着，此函数的调用者一定要传递一个 response 进来，否则接下来的代码无意义 function printOutside(response) { outside = response console.log(outside) } // ... // 接着在未来的某个时候，某个请求调用了 printOutside 函数，outside 被顺利赋值并打印$.getJSON('/some/api/endpoint', printOutside)实际上，最后的 $.getJSON 写在 printOutside 的前面或后面都无所谓，它总是能正确运行的，因为无论写前写后，同步代码的解释执行都会先于 printOutside 被调用。而作为函数声明 $.getJSON 也总是能找到正确的 printOutside 函数（hoisting）。 这就是你想知道的“怎样给外面用”的最核心的知识，我尽可能通俗的讲解了。不过现实中会有非常多复杂的情形，比如最常见的：“异步回调里面再异步请求回调再异步请求回调再……”，也就是俗称的“回调地狱”——就需要更复杂一些的手段来让它们乖乖听话。这些进阶的知识其实并不难，只是在我之前描述的概念之上更进一步罢了。 那么最后我在给你点明一下如何在这个概念上进阶一步。想想看如果你是 jQuery 的作者（或者其他类似异步请求函数的作者），你要如何定义 $.getJSON 这个函数？重点是：你如何赋予使用者自由定义回调函数，然后你能确保它正确运行？先自己想想，然后看下面的伪代码： // 这里，我要定义这个 getJSON；本质上，它是对一个 xhr 请求的封装 $.prototype.getJSON = function(path, callback) { // 使用者需要告诉我两个条件：1，请求的 path；2，请求返回后要执行的 callback // 接着我开始封装 xhr 请求，具体的代码请参考 javascript 的 API 手册 // 比如这里：https://developer.mozilla.org/en-US/docs/AJAX/Getting_Started var xhr = new XMLHttpRequest() // 初始化一个 xhr 对象 xhr.onreadystatechange = function() { // xhr 请求发出后会有多种状态变化（根据请求的发送及接受情况），这个函数用于处理各种状况 // 因此真实的代码这里会比较复杂，然而最终一切 OK 的话我们能获得正确的 response // 要注意的是，此函数必须在 send 之前定义，否则 send 完之后 xhr 对象并不知道该继续做什么 // 这也就暗示着，onreadystatechange 其实是 send 在某一时刻调用的 // 这与前面的 printOutside 的例子有异曲同工之妙 // 拿到 response 之后我们开始调用 callback，并把 response 传递进去 callback(xhr.responseText) } xhr.open('GET', path) // 配置 xhr 的请求参数 xhr.send() // 发送真正的请求 } 真正的 jQuery 自然要比这个伪代码例子复杂多了（就连 xhr 的封装都不是在这里做的，我没记错的话 jQuery 还有更底层的函数，$.ajax？），它要处理的问题可不仅仅是调用 callback 这么简单，不过一旦你从作者角度明确了 callback 是如何被调用的，那么从使用者的角度来考量该如何利用 callback 就变得自然而然毫无窒碍了，这也就是常说的“知其然并知其所以然”。 有心的话，再研究一个举一反三的小题目吧（不难），研究明白了就能再上一个台阶。题目如下： 我们已经了解了这样的写法和用法： $.getJSON('some/api/endpoint', function(response) { // do something... }) 那么这样的写法和用法又是怎么实现的呢？ $.getJSON('some/api/endpoint'[, maybeSomeAdditionalParams]) .success(function(response) { // do something when request is OK }) .fail(function(error) { // do something when it is NOT OK }) 一旦你掌握了这类写法是如何定义的，你就 get 到了新的姿势来处理可能存在的异步回调嵌套问题，并且这也是接下来你去学习更先进的异步编程范式的基础（比如 promises 等）。GL!