<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[lo_ong的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/github_37320188</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; github_37320188]]></copyright><item><title><![CDATA[java:继承]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/117156585</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/117156585</guid><author>github_37320188</author><pubDate>Fri, 17 Sep 2021 00:36:22 +0800</pubDate><description><![CDATA[1 类、超类和子类
假设你在某个公司工作，这个公司中经理的待遇与普通雇员的待遇存在着一些差异。不过， 他们之间也存在着很多相同的地方， 例如， 他们都领取薪水。只是普通雇员在完成本职任务之后仅领取薪水， 而经理在完成了预期的业绩之后还能得到奖金。这种情形就需要使用继承。
&nbsp;
这是因为需要为经理定义一个新类Manager, 以便增加一些新功能。但可以重用 Employee 类中已经编写的部分代码，并将其中的所有域保留下来。从理论上讲， 每个经理都是一名雇员：“ is-a” 关系是继承的一个明显特征。]]></description><category></category></item><item><title><![CDATA[java:对象与类]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/116570652</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/116570652</guid><author>github_37320188</author><pubDate>Fri, 21 May 2021 23:06:50 +0800</pubDate><description><![CDATA[1 面向对象程序设计概述
面向对象程序设计（简称OOP) 是当今主流的程序设计范型。

传统的结构化程序设计通过设计一系列的过程（即算法）来求解问题。一旦确定了这些过程， 就要开始考虑存储数据的方式。这就是Pascal 语言的设计者Niklaus Wirth 将其著作命名为《算法+ 数据结构= 程序》(Algorithms + Data Structures = Programs, Prentice Hall, 1975 )的原因。需要注意的是，在Wirth 命名的书名中， 算法是第一位的， 数据结构是第二]]></description><category></category></item><item><title><![CDATA[java:基本程序设计结构]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/116545971</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/116545971</guid><author>github_37320188</author><pubDate>Sun, 09 May 2021 00:04:50 +0800</pubDate><description><![CDATA[一个简单的 JAVA 应用程序
public class FirstSample
{
   public static void main(String[] args)
   {
      System.out.println("We will not use 'Hello, World!'");
   }
}



关键字public 称为访问修饰符（ access modifier ), 这些修饰符用于控制程序的其他部分对这段代码的访问级別
关键字class 表明Java 程序中的全部内容都包含在类中]]></description><category></category></item><item><title><![CDATA[java:语言发展历史]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/116545116</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/116545116</guid><author>github_37320188</author><pubDate>Sat, 08 May 2021 21:55:31 +0800</pubDate><description><![CDATA[]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第27章 可靠地进行产品的大规模发布]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/110578506</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/110578506</guid><author>github_37320188</author><pubDate>Thu, 03 Dec 2020 22:23:52 +0800</pubDate><description><![CDATA[发布协调工程师（Launch CoordinationEngineering,LCE）,LCE
（a）广泛的经验
（b）跨职能的视角
（c）客观性
&nbsp;
好的发布流程具有的一些特征：

轻量级：占用很少的开发时间
鲁棒性：能够最大限度地避免简单的错误。
完整性：完整地、一致地在各个环节内跟踪重要的细节问题。
可扩展性：可以应用在很多简单的发布上，也可以用在复杂的发布过程中。
适应性：适用于大多数常见的发布




这些需求是互相有冲突的。例如，想要设计一个流程来同时满足轻量级和完整性是很困难的，在.]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第26章 数据完整性：读写一致]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/109694264</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/109694264</guid><author>github_37320188</author><pubDate>Thu, 03 Dec 2020 21:42:12 +0800</pubDate><description><![CDATA[-数据完整性意味着用户可以维持对云服务的访问，用户对数据的访问能力是最重要的，所以这种访问能力的完整性非常重要。
&nbsp;

大多数云计算应用都是优化以下5项的某种组合：在线时间、延迟、规模、创新速度和隐私。

在线时间：经常也用“可用率（availability）”指代，代表着某个服务可以被用户使用的时间比率。
延迟：服务对用户的响应时间。
规模：某个服务的用户数量，以及能够维持正常服务水平的最高负载。
创新速度：某个服务能够在合理成本下，为用户提供更好的服务的创新速度。
隐私这个名词的定义比较复杂。]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第25章 数据处理流水线]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/109689412</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/109689412</guid><author>github_37320188</author><pubDate>Sat, 14 Nov 2020 13:46:05 +0800</pubDate><description><![CDATA[经典的数据处理方式是通过一个程序读取输入，执行某种模式变换，然后输出新的数据。一般来说，这种程序由类似于Cron的某个周期性的调度程序控制。这种设计模式被称为数据流水线（data pipeline）。经典的数据处理方式是通过一个程序读取输入，执行某种模式变换，然后输出新的数据。一般来说，这种程序由类似于Cron的某个周期性的调度程序控制。这种设计模式被称为数据流水线（data pipeline）。
&nbsp;
简单流水线设计模式与大数据

对大数据进行周期性的或者是持续性的变形操作的程序通常被称为“简单.]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第24章 分布式周期性任务系统]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/109689231</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/109689231</guid><author>github_37320188</author><pubDate>Sat, 14 Nov 2020 12:49:30 +0800</pubDate><description><![CDATA[最常见的执行时间表格式是所谓的“crontab”格式，这个格式支持使用简单的周期定义（例如，“每天中午执行一次”、“每小时整点的时候执行”）。也可以通过这种格式进行复杂的周期定义，例如，“仅仅在每月第30天，且当天为周六的时候执行”。
&nbsp;
一个可靠的大型分布式Cron系统所必须要解决的问题

跟踪Cron任务的状态，有两个选项：

将数据存储在一个可用度很高的外部分布式存储上。
系统内部自行存储一些（很小量的）状态信息。


Paxos协议的使用

保证副本状态的一致
单独的领头人任务，该副本是.]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第23章 管理关键状态：利用分布式共识来提高可靠性]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/109687176</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/109687176</guid><author>github_37320188</author><pubDate>Sat, 14 Nov 2020 12:26:42 +0800</pubDate><description><![CDATA[在构建可靠的、高可用的系统过程时，分布式共识系统适合用来维护某个强一致的系统状态。
&nbsp;
CAP理论： Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），论述了一个分布式系统不可能同时满足以下三个要求：
（1）每个节点上所见数据是一致的。
（2）每个节点都可以访问数据。
（3）可以承受网络分区问题。
&nbsp;
BASE理论：基本可用、软状态、最终一致性（basically available、softstate、eve.]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第22章 处理连锁故障]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/109082224</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/109082224</guid><author>github_37320188</author><pubDate>Mon, 09 Nov 2020 23:03:47 +0800</pubDate><description><![CDATA[连锁故障是由于正反馈循环（positivefeedback）导致的不断扩大规模的故障。


连锁故障可能由于整个系统的一小部分出现故障而引发，进而导致系统其他部分也出现故障。例如，某个服务的一个实例由于过载出现故障，导致其他实例负载升高，从而导致这些实例像多米诺骨牌一样一个一个全部出现故障。

&nbsp;

连锁故障产生的原因

（a）服务器过载：直接由于服务器过载导致，或间接由于服务器过载引发的其他问题导致

例如，某个集群内部的过载可能会导致该服务实例崩溃；这时负载均衡器会将请求发送给其他集群，使那.]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第21章 应对过载]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/109036132</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/109036132</guid><author>github_37320188</author><pubDate>Wed, 14 Oct 2020 20:14:31 +0800</pubDate><description><![CDATA[避免过载，是负载均衡策略的一个重要目标。但是无论你的负载均衡策略效率有多高，随着压力不断上升，系统的某个部位总会过载。运维一个可靠系统的一个根本要求，就是能够优雅地处理过载情况。
&nbsp;
简单地使用CPU数量作为资源配给的主要信号就可以工作得很好，原因如下：
（a）在有垃圾回收（GC）机制的编程环境里，内存的压力通常自然而然地变成CPU的压力（在内存受限的情况下，GC会增加）。
（b）在其他编程环境里，其他资源一般可以通过某种比例进行配置，以便使这些资源的短缺情况非常罕见。
&nbsp;
应对过载：.]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第20章 数据中心内部的负载均衡系统]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/108997953</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/108997953</guid><author>github_37320188</author><pubDate>Sat, 10 Oct 2020 16:32:06 +0800</pubDate><description><![CDATA[识别异常任务：流速控制和跛脚鸭任务
（a）流速控制机制也是一种非常简单的负载均衡机制：如果某个后端任务过载了，请求处理开始变慢，客户端会自动避开这个后端，从而将任务分配给其他的后端。
（b）跛脚鸭状态，后端任务正在监听端口，并且可以服务请求，但是已经明确要求客户端停止发送请求。


在Google的RPC框架实现中，不活跃的客户端（没有建立TCP连接的客户端）也会定期发送UDP健康检查包。这就使跛脚鸭状态可以相对较快地传递给所有的客户端—通常在一到两个RTT周期内—无论它们处于什么状态下。
&nbsp;
.]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第19章 前端服务器的负载均衡]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/108985419</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/108985419</guid><author>github_37320188</author><pubDate>Sat, 10 Oct 2020 14:58:20 +0800</pubDate><description><![CDATA[流量负载均衡（traffic load balancing）
&nbsp;
理想情况下，用户流量应该最优地分布于多条网络链路上、多个数据中心中，以及多台服务器上。但是这里的“最优”是如何定义的呢？最优严重依赖于下列几个因素：
（a）逻辑层级（是在全局还是在局部）。
（b）技术层面（硬件层面与软件层面）。
（c）用户流量的天然属性。


简化的场景：一个简单的搜索请求和一个视频上传请求。用户想要很快地获取搜索结果，所以对搜索请求来说最重要的变量是延迟（latency）。而对于视频上传请求来说，用户已经预期该.]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第18章 SRE部门中的软件工程实践]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/108983878</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/108983878</guid><author>github_37320188</author><pubDate>Fri, 09 Oct 2020 20:04:01 +0800</pubDate><description><![CDATA[SRE进行软件工程非常合适和有效的原因是：
（1）SRE组织内所拥有的Google特有的生产环境构建知识的深度和广度使得SRE工程师可以设计和实现出能够应对大规模部署，能够在灾难中优雅降级，可以和其他基础设施项目和工具良好集成的软件。
（2）SRE是自己工具的直接使用者，所以SRE能够深刻理解要开发工具的重点在哪里。
（3）与这些工具的直接用户——其他SRE——的密切联系使得获取直接的和高质量的用户反馈变得很容易。向一个对问题和解决方案都很熟悉的内部团体发布工具可以让开发团队更快地进行迭代。内部用户一般对.]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第17章 测试可靠性]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/108975275</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/108975275</guid><author>github_37320188</author><pubDate>Fri, 09 Oct 2020 18:27:46 +0800</pubDate><description><![CDATA[对服务质量的自信可以用过去的系统可靠度和未来的系统可靠度来衡量。前者可以通过抓取和分析历史性监控信息来获得，后者可以用基于历史数据的预测来量化。为了让这些预测信息足够准确，必须满足下列条件中之一：
（a）在这段时间内，该系统完全没有改变。包括没有任何软件更新以及服务器数量变化，这意味着未来的行为方式应该与过去的行为方式类似。
（b）可以充分描述整个系统的所有改变，这样可以针对每个系统变化引入的不确定性进行分析。
&nbsp;
软件测试的类型：传统测试和生产测试
（a）传统测试：

1）单元测试：单元测试（.]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第16章 跟踪故障]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/108975226</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/108975226</guid><author>github_37320188</author><pubDate>Fri, 09 Oct 2020 11:11:23 +0800</pubDate><description><![CDATA[提高可靠性的唯一可靠的方法论是建立一个基线（baseline），同时不断跟踪改变。
&nbsp;
消息系统
（a）消息聚合：能更好地消除重复报警，避免重复性工作。
（b）加标签：
（c）分析：包括计数和基本的汇总统计报告；环比。找到影响更广泛的问题。


...]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第15章 事后总结：从失败中学习]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/108974686</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/108974686</guid><author>github_37320188</author><pubDate>Fri, 09 Oct 2020 11:10:07 +0800</pubDate><description><![CDATA[基本的事后总结条件为：
（a）用户可见的宕机时间或者服务质量降级程度达到一定标准。
（b）任何类型的数据丢失。
（c）on-call 工程师需要人工介入的事故（包括回滚、切换用户流量等）。
（d）问题解决耗时超过一定限制。
（e）监控问题（预示着问题是由人工发现的，而非报警系统）。
&nbsp;
协作和知识共享
（a）实时协作：可以很快地收集数据和想法
（b）开放的评论系统：使大家都可以参与进来提供解决方案
（c）邮件通知：


...]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第14章 紧急事故管理]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/108934460</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/108934460</guid><author>github_37320188</author><pubDate>Mon, 05 Oct 2020 23:50:21 +0800</pubDate><description><![CDATA[紧急事故的流程管理要素
（a）嵌套式职责分离：在事故处理中，让每个人清楚自己的职责是非常重要的
（b）控制中心：受到事故影响的部门或者人需要知道他们可以与事故总控负责人联系。在很多情况下，可以设立一个“作战室”（warroom），将处理问题的全部成员挪到该地办公。
（c）实时事故状态文档
（d）明确公开的职责交接


以下是系统中可以分配给某个人的角色：

事故总控（incident command）：事故总控负责人掌握这次事故的概要信息。他们负责组建事故处理团队，按需求和优先级将一些任务分配给团队成员。.]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第13章 紧急事件响应]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/108934389</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/108934389</guid><author>github_37320188</author><pubDate>Mon, 05 Oct 2020 23:33:33 +0800</pubDate><description><![CDATA[向过去学习，而不是重复它
（a）为事故保留记录：在记录中，请一定要诚实，一定要事无巨细。尤其重要的是，提出关键的问题。时刻寻找如何能在战术及战略上避免这项事故的发生。公布和维护事后报告，确保全公司的每个人都能从中学到你所学到的知识。
（b）提出那些大的，甚至不可能的问题：假如……
（c）鼓励主动测试


...]]></description><category></category></item><item><title><![CDATA[读书笔记（SRE：Google运维解密）：第12章 有效的故障排查手段]]></title><link>https://blog.youkuaiyun.com/github_37320188/article/details/108933436</link><guid>https://blog.youkuaiyun.com/github_37320188/article/details/108933436</guid><author>github_37320188</author><pubDate>Mon, 05 Oct 2020 23:02:36 +0800</pubDate><description><![CDATA[新手们常常不能有效地进行故障排查，是因为这个过程理想情况下同时需要两个条件。
（a）对通用的故障排查过程的理解（不依靠任何特定系统）。
（b）对发生故障的系统的足够了解。
通用的故障排查流程
从理论上讲，我们将故障排查过程定义为反复采用假设-排除手段的过程：针对某系统的一些观察结果和对该系统运行机制的理论认知，我们不断提出一个造成系统问题的假设，进而针对这些假设进行测试和排除。


造成低效的故障排查过程的原因通常集中在定位（triage）、检查和诊断环节上，主要由于对系统不够了解而导致。

&nbsp;.]]></description><category></category></item></channel></rss>