停机问题

现象 测试同学反馈页面某功能有时候不能使用。 分析 根据页面返回结果和URL，从开发同学那里了解到该现象是新环境里a服务调b服务返回异常导致的。从多次请求的结果看来，大概50%的几率返回异常。按常理判断如果b服务有多个节点的，可能有其中个别节点异常会导致此现象发生，但是b服务只有一个节点，请求的同时，观察b服务的日志，在a调用结果异常的情况下，b没有任何日志输出，正常情况日志输出返回结果，说明请求没有到达b服务，如果对调用链路不熟的情况下完全可以抓包明确请求是否到达。那么调用失败的请求是去哪里了呢？调用链路如下： 图1 图1可以看出a调用b的地址是从consul-server上拿到的，在consul-server控制台看到的情况入下图： 图2 注：图中gw-mini是服务b 图2 中看到单节点的b服务，在consul注册中心上注册了两个实例，实际是这样吗？继续看下图： 图3 图3中b服务是单节点，ip是10.100.73.72，而consul-server中的另外一个地址10.100.73.75是其他服务的ip地址。在consul上b服务下面的两个实例健康检查都是正常状态，难怪a调用b老是出现异常的返回结果，a拿到的地址list里面有一个地址是不对的。为什么consul上b服务会有两个实例？看看异常实例10.100.73.75的详情，如下图： 图4 健康检查URL是b服务的没错

Dubbo优雅停机 背景 对于任何一个线上应用， 如何在服务更新部署过程中保证客户端无感知是开发者必须要解决的问题 ，即从应用停止到重启恢复服务这个阶段不能影响正常的业务请求。理想条件下，在没有请求的时候再进行更新是最安全可靠的，然而互联网应用必须要保证可用性，因此在技术层面上 优化应用更新流程来保证服务在更新时无损是必要的 。 传统的解决方式是通过将应用更新流程划分为手工摘流量、停应用、更新重启三个步骤，由人工操作实现客户端无对更新感知。这种方式简单而有效，但是限制较多：不仅需要使用借助网关的支持来摘流量，还需要在停应用前人工判断来保证在途请求已经处理完毕。这种需要人工介入的方式运维复杂度较高，只能适用规模较小的应用，无法在大规模系统上使用。 因此，如果在容器/框架级别提供某种自动化机制，来自动进行摘流量并确保处理完已到达的请求，不仅能保证业务不受更新影响，还可以极大地提升更新应用时的运维效率。 这个机制也就是 优雅停机 ，目前Tomcat/Undertow/Dubbo等容器/框架都有提供相关实现。下面给出正式一些的定义：优雅停机是指在停止应用时，执行的一系列保证应用正常关闭的操作。这些操作往往包括等待已有请求执行完成、关闭线程、关闭连接和释放资源等，优雅停机可以避免非正常关闭程序可能造成数据异常或丢失，应用异常等问题。 优雅停机本质上是JVM即将关闭前执行的一些额外的处理代码。

上回我们介绍了两种有穷自动机模型——确定性有穷自动机DFA和非确定性有穷自动机，以及从正则表达式经过NFA最终转化为DFA的算法。有些同学表示还是难以理解NFA到底怎么转化为DFA。所以本篇开头时我想再多举一个例子，看看NFA转化为DFA之后到底是什么样。首先我们看下面的NFA，它是从一组词法分析所用的正则表达式转换而来的。这个NFA合并了IF、ID、NUM、error这四个单词的NFA。因此，它的四个接受状态分别代表遇到了四种不同的单词。 用上一篇学到的方法，我们需要求出一个DFA，它的每个状态都是NFA状态集合的一个子集。首先我们要定义任何状态的ε-闭包，之所以叫ε-闭包，是因为它对ε转换而言是封闭的，也就是说ε-闭包内任何状态，经过ε转换之后，都还是闭包内的一个状态。接下来，从初始状态ε-闭包开始，我们要计算输入任何一种字符后，NFA所能转换到的下一个状态集合。这一步的公式是： 其中那个U型的符号，表示：对NFA状态集合d中的任何状态s，求出s在遇到符号c之后所能达到的所有状态组成的集合，再把所有这种集合求并集。最后，再对这个集合求出ε-闭包。我很难找出一种更简单的描述方式，简而言之就是要计算出NFA状态集合d，在输入符号c之后，所能达到的一切状态的新集合。而这个集合，就会变成DFA的一个状态，这个状态是从d，沿着一条标有c的边达到的。我们首先求出初始状态的ε

摘要：数据中心为企业关键业务的发展提供了重要了支撑。但与此同时，其也有自己的成长和巩固周期。更大的数据利用率和吞吐量意味着需要消耗更多的服务器和机架资源，这反过来也就意味着更多的热量和电力问题，这不可避免地导致了数据中心本身的升级或整合需求。加之这一新兴的环境和相关的能源消费规定，很容易理解数据中心管理人员会发现自己几乎永远处在一个改变的状态。 虽然数据中心仍是一个新兴的行业，其目的还是建造相关的设施以便为企业提供有吸引力的、能够帮助企业解决并适应各种需求。由于成本因素和新的基础设施更新升级等相关问题，改造和升级占到了数据中心的变化的绝大多数。 那么，企业需要如何在不停机的情况下准备一个成功的数据中心升级呢? 考虑业务相关的问题，而不是IT 首先，这也是最重要的一步：便是要充分了解数据中心的升级是一个业务问题，而不是IT问题。现场实时升级是由业务需求驱动的，以便能够帮助企业降低成本、减少中断。因此，在这种情况下，准备现场实时升级必须以企业业务本身的策划为蓝本是至关重要的。 这种做法也是因为涉及到企业的商业利益。您需要提前列出一个可能的风险清单列表，以防止数据中心的升级失败影响到核心业务流程：通讯、电子邮件、客户账户和服务、可审计跟踪数据的维护、以及许多需要知会董事会知晓的其他方面，毕竟现场实时升级是一个重要的商业项目。 正确供应项目 建立现场实时升级的相关规范，而不是“一切照常

程序语言编年史 概述 这次咱们聊下程序语言的发展史，除了程序语言，还会着重讲下程序语言密切相关的计算机的发展史，顺带讲下同时期与程序语言和计算机相关领域的发展,为什么要把程序语言和计算机相关领域放到一块讲, 因为这些领域和计算机的关系太密切了, 程序语言是 程序员 和计算机沟通交流唯一方式, 计算机的计算模型的发展, 还有计算机的应用领域的发展都对程序语言有着深刻的影响. 通过计算机相关领域的发展, 我们能从中可以找到一些影响程序语言关键因素, 看看 这些因素是如何推动程序语言一步步发展成今天这个样子的. 计算机发展史 计算机的发展可以分为两条线进行追溯, 一条是计算理论的发展, 一条是计算机实体的发展, 下面我们看看计算理论和计算机的发展轨迹. 理论模型的演变 计算理论是近现代才出现的一个数学分支,主要研究可计算性,计算的复杂度,计算模型(计算理论中两大计算模型:图灵机,lambda演算),形式语言(编程语言也是一种形式语言).我们可以看到计算理论主要研究的对象的名字中有三个带了 计算 ; 计算 这个词很常见,好像和这些词汇所表达的意思挺相近:四则运算,数值计算,逻辑运算.本节就以 计算 为主线介绍下计算是什么,以及其演变历史,还有它和计算理论的关系. 史前数学：数值计算 公元前2500年,在美索不达米亚的一块泥板上记录着谷仓里面有1152000,每个人分7分,可以分给多少人

20191323《信息安全系统设计基础》第二周学习总结 教材学习内容总结 第二周主要进行了 第一章 和 第十八章 的学习 第一章 主要学习了计算机系统的组成以及计算机的历史等，对日常真直接或间接接触的计算机有了更深一步的认识，同时也明白计算机是当代人类智慧的结晶，更加激起我对语言学习的热情。 第十八章 主要学习了计算的限制，明白了即使到了今天在科技如此发达的情况下计算在硬件上和软件上存在着限制，人类的科技仍有巨大的进步空间，同时我也在停机问题和算法分类上产生了一定的问题和思考 教材学习中的问题和解决过程 问题1：为什么要研究停机问题，停机问题会对计算机造成哪些影响？ 问题1解决方案： 研究病毒的原理是已停机问题为基础展开的，停机问题和破坏计算机硬件系统占用计算机资源 问题2：阶乘时间为什么比指数时间更耗时？ 问题2解决方案： 因为随着数据量的增加，对数阶，幂函数阶的算法时间开销增加速度逐渐减小，而指数阶阶乘阶消耗时间增加速度太快，但数据量达到一定程度的时候，前者消耗的时间依然在可接受范围内，而后者将超出可接受时间。 代码调试中的问题和解决过程 问题1：在安装pyinstaller时遇到you are using pip version 19.0.3, however 19.2.3 is available. 问题1的解决方案：暂时没有解决，问题已提交云班课答疑。 来源： https

fdisk分区后不停机加载内核分区表 问题描述： fdisk分完区保存之后，系统提示 The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) 意思是内核还用旧的分区表信息，新的分区表会在重启或者执行partprobe or kpartc之后使用 解答 # fdisk -l # 查看分区信息 # cat /proc/partitions 查看内存的分区表 没有把新的分区加载进去 使用如下命令： # partx -a /dev/sdb命令，执行之后查看内核分区表 # cat /proc/partitions 已经成功加载进去 来源： https://www.cnblogs.com/l-mac/p/11522524.html

　　在公共云迁移过程中，IT团队需要采取一种一步一随的谨慎做法以避免发生可怕的“系统关闭”事件。 　　随着众多企业迁移至基于云的基础设施，IT团队需要确保在迁移过程中的可用性。但是考虑到所涉及的复杂性，在云迁移过程中防止或最小化停机时间并不容易。云团队需要考虑数据的不一致性、监控不同的软件版本并检查其网络连接是否成功。 　　如果企业的应用程序停用，那么其业务就会中断。虽然精确的指标因具体公司和应用而有所不同，但是Gartner在2014年发现，网络停机事件的平均成本为5，600美元/分钟。停机事件的高昂成本也是企业通常将他们最负责工作负载迁移至其他平台（包括云）的原因之一。 　　企业用户仍然以一个较快的速度扩大着公共云的应用范围。Forrester Research预测，2017年全球公共云市场将达到1460亿美元，高于2015年的870亿美元。 　　看不清的前景 　　对于选择迁移至云的企业来说，未来的前景是有好有坏的。任何的云迁移过程都是困难的。移动信息需要付出大量的时间与精力，即便生产系统与目标系统是完全兼容的。您的云供应商所运行系统与用户内部使用系统相同的可能性极小，所以云迁移挑战难度呈指数级增长。 　　在另一方面，如今的计算基础设施较以往更显模块化。 　　“虚拟化使企业更容易地实现不同系统之间的工作负载迁移，”Forrester