lo_ong的博客

原创 java:继承

1 类、超类和子类假设你在某个公司工作，这个公司中经理的待遇与普通雇员的待遇存在着一些差异。不过， 他们之间也存在着很多相同的地方， 例如， 他们都领取薪水。只是普通雇员在完成本职任务之后仅领取薪水， 而经理在完成了预期的业绩之后还能得到奖金。这种情形就需要使用继承。 这是因为需要为经理定义一个新类Manager, 以便增加一些新功能。但可以重用 Employee 类中已经编写的部分代码，并将其中的所有域保留下来。从理论上讲， 每个经理都是一名雇员：“ is-a” 关系是继承的一个明显特征。

原创 java:对象与类

1 面向对象程序设计概述面向对象程序设计（简称OOP) 是当今主流的程序设计范型。传统的结构化程序设计通过设计一系列的过程（即算法）来求解问题。一旦确定了这些过程， 就要开始考虑存储数据的方式。这就是Pascal 语言的设计者Niklaus Wirth 将其著作命名为《算法+ 数据结构= 程序》(Algorithms + Data Structures = Programs, Prentice Hall, 1975 )的原因。需要注意的是，在Wirth 命名的书名中， 算法是第一位的， 数据结构是第二

原创 java:基本程序设计结构

一个简单的 JAVA 应用程序public class FirstSample{ public static void main(String[] args) { System.out.println("We will not use 'Hello, World!'"); }}关键字public 称为访问修饰符（ access modifier ), 这些修饰符用于控制程序的其他部分对这段代码的访问级別关键字class 表明Java 程序中的全部内容都包含在类中

原创 java:语言发展历史

原创 读书笔记（SRE：Google运维解密）：第27章 可靠地进行产品的大规模发布

发布协调工程师（Launch CoordinationEngineering,LCE）,LCE（a）广泛的经验（b）跨职能的视角（c）客观性 好的发布流程具有的一些特征：轻量级：占用很少的开发时间鲁棒性：能够最大限度地避免简单的错误。完整性：完整地、一致地在各个环节内跟踪重要的细节问题。可扩展性：可以应用在很多简单的发布上，也可以用在复杂的发布过程中。适应性：适用于大多数常见的发布这些需求是互相有冲突的。例如，想要设计一个流程来同时满足轻量级和完整性是很困难的，在.

原创 读书笔记（SRE：Google运维解密）：第26章 数据完整性：读写一致

-数据完整性意味着用户可以维持对云服务的访问，用户对数据的访问能力是最重要的，所以这种访问能力的完整性非常重要。 大多数云计算应用都是优化以下5项的某种组合：在线时间、延迟、规模、创新速度和隐私。在线时间：经常也用“可用率（availability）”指代，代表着某个服务可以被用户使用的时间比率。延迟：服务对用户的响应时间。规模：某个服务的用户数量，以及能够维持正常服务水平的最高负载。创新速度：某个服务能够在合理成本下，为用户提供更好的服务的创新速度。隐私这个名词的定义比较复杂。

原创 读书笔记（SRE：Google运维解密）：第25章 数据处理流水线

经典的数据处理方式是通过一个程序读取输入，执行某种模式变换，然后输出新的数据。一般来说，这种程序由类似于Cron的某个周期性的调度程序控制。这种设计模式被称为数据流水线（data pipeline）。经典的数据处理方式是通过一个程序读取输入，执行某种模式变换，然后输出新的数据。一般来说，这种程序由类似于Cron的某个周期性的调度程序控制。这种设计模式被称为数据流水线（data pipeline）。 简单流水线设计模式与大数据对大数据进行周期性的或者是持续性的变形操作的程序通常被称为“简单.

原创 读书笔记（SRE：Google运维解密）：第24章 分布式周期性任务系统

最常见的执行时间表格式是所谓的“crontab”格式，这个格式支持使用简单的周期定义（例如，“每天中午执行一次”、“每小时整点的时候执行”）。也可以通过这种格式进行复杂的周期定义，例如，“仅仅在每月第30天，且当天为周六的时候执行”。 一个可靠的大型分布式Cron系统所必须要解决的问题跟踪Cron任务的状态，有两个选项：将数据存储在一个可用度很高的外部分布式存储上。系统内部自行存储一些（很小量的）状态信息。Paxos协议的使用保证副本状态的一致单独的领头人任务，该副本是.

原创 读书笔记（SRE：Google运维解密）：第23章 管理关键状态：利用分布式共识来提高可靠性

在构建可靠的、高可用的系统过程时，分布式共识系统适合用来维护某个强一致的系统状态。 CAP理论： Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），论述了一个分布式系统不可能同时满足以下三个要求：（1）每个节点上所见数据是一致的。（2）每个节点都可以访问数据。（3）可以承受网络分区问题。 BASE理论：基本可用、软状态、最终一致性（basically available、softstate、eve.

原创 读书笔记（SRE：Google运维解密）：第22章 处理连锁故障

连锁故障是由于正反馈循环（positivefeedback）导致的不断扩大规模的故障。连锁故障可能由于整个系统的一小部分出现故障而引发，进而导致系统其他部分也出现故障。例如，某个服务的一个实例由于过载出现故障，导致其他实例负载升高，从而导致这些实例像多米诺骨牌一样一个一个全部出现故障。 连锁故障产生的原因（a）服务器过载：直接由于服务器过载导致，或间接由于服务器过载引发的其他问题导致例如，某个集群内部的过载可能会导致该服务实例崩溃；这时负载均衡器会将请求发送给其他集群，使那.

原创 读书笔记（SRE：Google运维解密）：第21章 应对过载

避免过载，是负载均衡策略的一个重要目标。但是无论你的负载均衡策略效率有多高，随着压力不断上升，系统的某个部位总会过载。运维一个可靠系统的一个根本要求，就是能够优雅地处理过载情况。 简单地使用CPU数量作为资源配给的主要信号就可以工作得很好，原因如下：（a）在有垃圾回收（GC）机制的编程环境里，内存的压力通常自然而然地变成CPU的压力（在内存受限的情况下，GC会增加）。（b）在其他编程环境里，其他资源一般可以通过某种比例进行配置，以便使这些资源的短缺情况非常罕见。 应对过载：.

原创 读书笔记（SRE：Google运维解密）：第20章 数据中心内部的负载均衡系统

识别异常任务：流速控制和跛脚鸭任务（a）流速控制机制也是一种非常简单的负载均衡机制：如果某个后端任务过载了，请求处理开始变慢，客户端会自动避开这个后端，从而将任务分配给其他的后端。（b）跛脚鸭状态，后端任务正在监听端口，并且可以服务请求，但是已经明确要求客户端停止发送请求。在Google的RPC框架实现中，不活跃的客户端（没有建立TCP连接的客户端）也会定期发送UDP健康检查包。这就使跛脚鸭状态可以相对较快地传递给所有的客户端—通常在一到两个RTT周期内—无论它们处于什么状态下。 .

原创 读书笔记（SRE：Google运维解密）：第19章 前端服务器的负载均衡

流量负载均衡（traffic load balancing） 理想情况下，用户流量应该最优地分布于多条网络链路上、多个数据中心中，以及多台服务器上。但是这里的“最优”是如何定义的呢？最优严重依赖于下列几个因素：（a）逻辑层级（是在全局还是在局部）。（b）技术层面（硬件层面与软件层面）。（c）用户流量的天然属性。简化的场景：一个简单的搜索请求和一个视频上传请求。用户想要很快地获取搜索结果，所以对搜索请求来说最重要的变量是延迟（latency）。而对于视频上传请求来说，用户已经预期该.

原创 读书笔记（SRE：Google运维解密）：第18章 SRE部门中的软件工程实践

SRE进行软件工程非常合适和有效的原因是：（1）SRE组织内所拥有的Google特有的生产环境构建知识的深度和广度使得SRE工程师可以设计和实现出能够应对大规模部署，能够在灾难中优雅降级，可以和其他基础设施项目和工具良好集成的软件。（2）SRE是自己工具的直接使用者，所以SRE能够深刻理解要开发工具的重点在哪里。（3）与这些工具的直接用户——其他SRE——的密切联系使得获取直接的和高质量的用户反馈变得很容易。向一个对问题和解决方案都很熟悉的内部团体发布工具可以让开发团队更快地进行迭代。内部用户一般对.

原创 读书笔记（SRE：Google运维解密）：第17章 测试可靠性

对服务质量的自信可以用过去的系统可靠度和未来的系统可靠度来衡量。前者可以通过抓取和分析历史性监控信息来获得，后者可以用基于历史数据的预测来量化。为了让这些预测信息足够准确，必须满足下列条件中之一：（a）在这段时间内，该系统完全没有改变。包括没有任何软件更新以及服务器数量变化，这意味着未来的行为方式应该与过去的行为方式类似。（b）可以充分描述整个系统的所有改变，这样可以针对每个系统变化引入的不确定性进行分析。 软件测试的类型：传统测试和生产测试（a）传统测试：1）单元测试：单元测试（.

原创 读书笔记（SRE：Google运维解密）：第16章 跟踪故障

提高可靠性的唯一可靠的方法论是建立一个基线（baseline），同时不断跟踪改变。 消息系统（a）消息聚合：能更好地消除重复报警，避免重复性工作。（b）加标签：（c）分析：包括计数和基本的汇总统计报告；环比。找到影响更广泛的问题。...

原创 读书笔记（SRE：Google运维解密）：第15章 事后总结：从失败中学习

基本的事后总结条件为：（a）用户可见的宕机时间或者服务质量降级程度达到一定标准。（b）任何类型的数据丢失。（c）on-call 工程师需要人工介入的事故（包括回滚、切换用户流量等）。（d）问题解决耗时超过一定限制。（e）监控问题（预示着问题是由人工发现的，而非报警系统）。 协作和知识共享（a）实时协作：可以很快地收集数据和想法（b）开放的评论系统：使大家都可以参与进来提供解决方案（c）邮件通知：...

原创 读书笔记（SRE：Google运维解密）：第14章 紧急事故管理

紧急事故的流程管理要素（a）嵌套式职责分离：在事故处理中，让每个人清楚自己的职责是非常重要的（b）控制中心：受到事故影响的部门或者人需要知道他们可以与事故总控负责人联系。在很多情况下，可以设立一个“作战室”（warroom），将处理问题的全部成员挪到该地办公。（c）实时事故状态文档（d）明确公开的职责交接以下是系统中可以分配给某个人的角色：事故总控（incident command）：事故总控负责人掌握这次事故的概要信息。他们负责组建事故处理团队，按需求和优先级将一些任务分配给团队成员。.

原创 读书笔记（SRE：Google运维解密）：第13章 紧急事件响应

向过去学习，而不是重复它（a）为事故保留记录：在记录中，请一定要诚实，一定要事无巨细。尤其重要的是，提出关键的问题。时刻寻找如何能在战术及战略上避免这项事故的发生。公布和维护事后报告，确保全公司的每个人都能从中学到你所学到的知识。（b）提出那些大的，甚至不可能的问题：假如……（c）鼓励主动测试...

原创 读书笔记（SRE：Google运维解密）：第12章 有效的故障排查手段

新手们常常不能有效地进行故障排查，是因为这个过程理想情况下同时需要两个条件。（a）对通用的故障排查过程的理解（不依靠任何特定系统）。（b）对发生故障的系统的足够了解。通用的故障排查流程从理论上讲，我们将故障排查过程定义为反复采用假设-排除手段的过程：针对某系统的一些观察结果和对该系统运行机制的理论认知，我们不断提出一个造成系统问题的假设，进而针对这些假设进行测试和排除。造成低效的故障排查过程的原因通常集中在定位（triage）、检查和诊断环节上，主要由于对系统不够了解而导致。 .

原创 读书笔记（SRE：Google运维解密）：第11章 on-call轮值

作为生产系统的监管者，on-call工程师负责处理生产环境中即将或者正在发生的业务事故，以及评审对生产系统的变更请求。 紧急事件（incident）的定义是：一系列根本原因一致或者相关的事件和报警信息，这些事件应该在同一个事后报告中讨论 现代理论研究指出，在面临挑战时，一个人会主动或非主动（潜意识）地选择下列两种处理方法之一：（a）依赖直觉，自动化、快速行动。（b）理性、专注、有意识地进行认知类活动。 在应急事件处理过程中，最理想的方法论是这样的：在有足够数据.

原创 读书笔记（SRE：Google运维解密）：第10章 基于时间序列数据进行有效报警

服务可靠度层级模型监控（a）埋点（b）指标收集：指标合成（c）时间序列数据存储（d）规则计算（e）报警 汇总计算（aggregation），是分布式环境中不可缺少的一环。汇总计算过程可以将一个任务的所有实例中的某个time-series相加。通过计算总数，我们就可以计算整体速率（rate）。例如：一个任务在整个数据中心中的整体每秒查询率（QPS）需要通过所有实例的查询计数器[14]的变化率的总和[15]来计算。 命运共享（share of fate）理念建.

原创 读书笔记（SRE：Google运维解密）：第9章 简单化

软件系统本质上是动态的和不稳定的。 有的时候为了灵活性而牺牲稳定性是有意义的 为了最小化意外复杂度，SRE团队应该：（a）在他们所负责的系统中引入意外复杂度时，及时提出抗议。（b）不断地努力消除正在接手的和已经负责运维的系统的复杂度。 所有的代码都有必须存在的目的的实践："代码膨胀"检测 软件的简单性是可靠性的前提条件。当我们考虑如何简化一个给定的任务的每一步时，我们并不是在偷懒。相反，我们是在明确实际上要完成的任务是什么，以及如何更容易地做到。.

原创 读书笔记（SRE：Google运维解密）：第8章 发布工程

发布工程师通常对源代码管理、编译器、构建配置语言、自动化构建工具、包管理器和安装器等非常了解（甚至是这方面的专家）。技能横跨很多领域：开发、配置管理、测试集成、系统管理，甚至用户支持。 发布工程哲学：（a）自服务模型：发布过程是真正的自动化的，工程师仅仅在发生问题时才会进行干预。（b）追求速度：“测试通过即发布”（Push OnGreen）发布模型（c）密闭性：构建过程都是密闭的（hermetic），意味着它们不受构建机器上安装的第三方类库或者其他软件工具所影响。构建过程使用指定版本.

原创 读书笔记（SRE：Google运维解密）：第7章 Google 的自动化系统的演进

自动化是一种力量倍增器，但不是万能药。当然，对力量的倍增并不能改变力量用在哪的准确性：草率地进行自动化可能在解决问题的同时产生出其他问题。 自动化的价值究竟是什么？（a）一致性：一致性地执行范围明确、步骤已知的程序—是自动化的首要价值。（b）平台性：一个平台可以暴露自身的性能指标，也可以帮助你发现流程中以前所不知道的细节，这些细节在平台范围内更容易衡量。（c）修复速度更快：在产品生命周期中一个问题越晚被发现，修复代价越高；（d）行动速度更快：（e）节省时间：节省时间是一个经常被引用.

原创 读书笔记（SRE：Google运维解密）：第6章 分布式系统的监控

绝大部分通用的术语：（a）监控（monitoring）：收集、处理、汇总，并且显示关于某个系统的实时量化数据，例如请求的数量和类型，错误的数量和类型，以及处理用时，应用服务器的存活时间等（b）白盒监控（white-box monitoring）：依靠系统内部暴露的一些性能指标进行监控。包括日志分析、Java虚拟机提供的监控接口，或者一个列出内部统计数据的HTTP接口进行监控。（c）黑盒监控（black-box monitoring）：通过测试某种外部用户可见的系统行为进行监控。（d）监控台页面（d.

原创 读书笔记（SRE：Google运维解密）：第5章 减少琐事

如果系统正常运转中需要人工干预，应该将此视为一种Bug。 到底什么是琐事？琐事就是运维服务中手动性的，重复性的，可以被自动化的，战术性，没有持久价值的工作。而且，琐事与服务呈线性关系的增长。每件琐事都满足下列一个或多个属性：（a）手动性：手动运行脚本以便自动执行一些任务（b）不停反复做的工作。如果你正在解决一个新出现的问题或者寻求一种新的解决办法，不算作琐事。（c）可以被自动化的（d）战术性的：突然出现的、应对式的工作，而非策略驱动和主动安排的。处理紧急警报是琐事。我们可能永远无法完.

原创 读书笔记（SRE：Google运维解密）：第4章 服务质量目标

服务质量指标（SLI）、服务质量目标（SLO）、服务质量协议（SLA）这三项分别是指该服务最重要的一些基础指标、这些指标的预期值，以及当指标不符合预期时的应对计划 大部分服务都将请求延迟—处理请求所消耗的时间——作为一个关键SLI（a）其他常见的SLI包括错误率（请求处理失败的百分比）、系统吞吐量（每秒请求数量）等（b）可用性（availability）是另外一个SRE重视的SLI，代表服务可用时间的百分比（c）运维行业经常用9的数量来描述可用程度。例如，99%可用性被称为“2个9”.

原创 读书笔记（SRE：Google运维解密）：第3章 拥抱风险

极端的可靠性会带来成本的大幅提升：过分追求稳定性限制了新功能的开发速度和将产品交付给用户的速度，并且很大程度地增加了成本，这反过来又减少了一个团队可以提供的新功能的数量 可靠性进一步提升的成本主要存在于以下两个维度（a）冗余物理服务器/计算资源的成本（b）机会成本基于时间的可用性可用性=系统正常运行时间/（系统正常运行时间+停机时间）通过请求成功率来定义服务可用性可用性=成功请求数/总的请求数在一个正式的环境或安全关键的系统中，服务的风险容忍度通常是直接根据..

原创 读书笔记（SRE：Google运维解密）：第2章 Google 生产环境：SRE视角

物理服务器（machine）代表具体的硬件（有时候也代表一个VM 虚拟机）。 软件服务器（server）代表一个对外提供服务的软件系统。 典型的Google数据中心的拓扑结构：（a）约10台物理服务器组成了一个机柜（Rack）（b）数台机柜组成一个机柜排（Row）（c）一排或多排机柜组成了一个集群（Cluster）（d）一般来说，一个数据中心（Datacenter）包含多个集群（e）多个相邻的数据中心组成了一个园区（Campus） 支..

原创 读书笔记（SRE：Google运维解密）：第1章 概览

SRE究竟是如何在Google起源的？SRE就是让软件工程师来设计一个新型运维团队的结果 SRE团队成员具有如下特点：（a）对重复性、手工性的操作有天然的排斥感。（b）有足够的技术能力快速开发出软件系统以替代手工操作。 Google的经验法则SRE团队必须将50%的精力花在真实的开发工作上 DevOps核心思想是尽早将IT相关技术与产品设计和开发过程结合起来，着重强调自动化而不是人工操作，以及利用软件工程手段执行运维任务等 ..

原创 go:pprof 性能分析

什么是pprof？代码上线前可以通过压测可以获知系统的性能，例如每秒能处理的请求数，平均响应时间，错误率等指标。可以对性能有初步的估计但是压测是线下的模拟流量，线上可能会遇到高并发、大流量，不靠谱的上下游，突发的尖峰流量等等场景，这些都是不可预知的。线上突然大量报警，接口超时，错误数增加，除了看日志、监控，就是用性能分析工具分析程序的性能，找到瓶颈。当然，一般这种情形不会让你有机会去分析，降级、限流、回滚才是首先要做的，要先止损。回归正常之后，通过线上流量回放，或者压测等手段，制造性能问题，再通过工具

原创 mac:brew安装配置mysql，创建用户用进行授权

1.安装mysql，并修改root密码为root# 安装mysql，默认8.0以上brew install mysql# 设置mysql开机启动#（1）首先确认~/Library/LaunchAgents目录存不存在，若存在则无需创建#（2）建立软链接#（3）设置自启动mkdir -p ~/Library/LaunchAgentsln -sfv /usr/local/opt/mysql/*.plist ~/Library/LaunchAgentslaunchctl load -w ~/L

原创 sublime:下载免费历史版本

sublime作为最好用的工具，曾经是一直免费的。一直到3.1某个版本之后开始需要在线激活认证，破解一是容易出问题，二是还算是盗版。历史版本中虽然还有bug（一直持续不断更新版本就是为了解决bug，其次才是加入新功能），但是基本够日常需求，然而官网时不提供历史版本下载链接的，但并不代表不能下载。 https://download.sublimetext.com/Sublime%20Text%20...

原创 Cloudera manager:自动化脚本部署

实验环境笔记本：macbook pro，32G memory虚拟机：VirtualBox，3台 centos7 虚拟机(均最小化安装)node1 默认为 master(或者说是server)：2 CPU，5G memory，200G 存储（动态分配），桥接网络（配置静态 IP 192.168.1.155）node1 默认为 agent：1 CPU，2G memory，200G 存储（动态...

翻译 AutoML：最新技术概览

原文链接：https://arxiv.org/pdf/1908.00709.pdfXin He, Kaiyong Zhao, Xiaowen Chu∗Department of Computer Science, Hong Kong Baptist UniversityEmail: {csxinhe, kyzhao, chxw}@comp.hkbu.edu.hkAbstract深度学...

原创 Deep Learning:PyTorch 基于docker 容器的分布式训练实践

引言PyTorch distributed currently only supports Linux. 这句话是来自 pytorch 官网 的 torch.distributed 部分，说明 pytorch 支持分布式训练，而且只在linux 上支持。 torch.distributed supports three backends, each with dif...

原创 Deep Learning:MXNet 基于docker 容器的分布式训练实践

引言MXNet supports distributed training enabling us to leverage multiple machines for faster training. MXNet支持分布式培训，使我们能够利用多台机器进行更快速的培训。这段话来自于 MXNet官网 ，说明了MXNet 支持跨越设备运行。 How to Start Dis...

翻译 白皮书:InfiniBand简介

原文链接：Introduction to InfiniBand摘要InfiniBand是一种功能强大的新架构，旨在支持Internet基础设施的 I/O 连接。 所有主要OEM服务器供应商都支持InfiniBand作为扩展服务器以及在服务器中创建下一代 I/O 互连标准的手段。 大批量工业标准 I/O互连首次扩展了传统“盒中”总线的作用。 InfiniBand 独一无二的提供“盒中”背板解决方...

原创 conda:虚拟环境 bug 问题解决

Q1 使用 pip 安装 torch 失败问题描述：在 centos 7 虚拟机中 使用 miniconda 创建的虚拟环境。创建完成后，可以使用conda 安装python 相关 lib但是不能使用pip 安装，报错如下问题原因：是因为虚拟机时间 有问题，需要将时间校准就能 解决# 安装ntpsudo yum -y install ntp# 测试 ntpntpdate poo...