DevOps

可参考码农翻身《什么是DevOps》
目前对 DevOps 有太多的说法和定义，不过它们都有一个共同的思想：“解决开发者与运维者之间曾经不可逾越的鸿沟，增强开发者与运维者之间的沟通和交流”。而我个人认为，DevOps 可以用一个公式表达：

文化观念的改变 + 自动化工具 = 不断适应快速变化的市场 其核心价值在于以下两点：

• 更快速地交付, 响应市场的变化。
• 更多地关注业务的改进与提升。

IT技术架构也随着系统的复杂化而不断地变化革新，从早期所有服务的All In One发展到现在的微服务架构、从纯手动操作到全自动化流程、从单台物理机到云平台，下图展示了IT技术革新的变化： 其实DevOps核心思想就是：“快速交付价值，灵活响应变化”。其基本原则如下：

• 高效的协作和沟通
• 自动化流程和工具
• 快速敏捷的开发
• 持续交付和部署
• 不断学习和创新

个人摘录码农翻身文章的理解：

• 研发团队要微服务改造，为频繁部署做准备，也方便快速回滚。

• 研发和运维不能互相推卸责任，互相指责，而要共同担责了。一个项目的开发、部署、维护，是研发和运维双方的事情，双方都要对业务负责，出了什么问题，要通力合作，共同解决。
• 运维人员也要了解业务，Code变化带来的影响要告知运维人员
• 开发人员工作的开发/测试环境要尽可能地和生产环境一致
• 部署工作要完全自动化起来，部署的脚本由运维部门主导，有问题研发部门来辅助，将来这个部署脚本要在所有的环境都用起来！
• 要有度量指标去衡量DevOps，例如失败部署的百分比，用户开的ticket数目，故障恢复的平均时间等等
• 无论用了什么工具、方法，如果最后没有减少需求从提出到上线，交付给用户使用的时间，那都是失败的，想尽办法去减少这个时间，不是一次、两次，而是持续、稳定地交付给用户。

何为分布式系统

维基百科定义：

分布式系统是一种其组件位于不同的联网计算机上的系统，然后通过互相传递消息来进行通信和协调。为了达到共同的目标，这些组件会相互作用

• 服务化的确是分布式系统，但分布式系统不仅仅停留在那些服务化的模式（SOA、ESB、微服务...）上。

服务化的本质是“分治”，而“分治”的前提是先要拆，然后才谈得上如何治。这时，高内聚、低耦合的思想在拆分过程中起到了一个非常重要的作用

• 分布式系统中会运用中间件（MQ、RPC、DAL...），但分布式系统却不仅仅停留在用了什么中间件上

中间件起到的是标准化的作用。中间件只是承载这些标准化想法的介质、工具，可以起到引导和约束的效果，以此起到大大降低系统复杂度和协作成本的作用。

看待一个“分布式系统”的时候，内在胜于表象。其实，只要涉及多个进程协作才能提供一个完整功能的系统，就是“分布式系统”。

分布式系统本质

转自 InfoQ 张帆:《分布式系统的本质其实就是这两个问题》

分 治

分治，字面意思是“分而治之”，和我们的大脑在解决问题时的思考方式是一样的。我们可以将整个过程分为 3 步：分解 -> 治理 -> 归并。而分治思想的表现形式多样，分层、分块都是它的体现。
这么做的好处是：问题越小越容易被解决，并且，只要解决了所有子问题，父问题就都可以被解决了。但是，这么做的时候，需要满足一个最重要的条件：不同分支上的子问题，不能相互依赖，需要各自独立。因为一旦包含了依赖关系，子问题和父问题之间就失去了可以被“归并”的意义。在软件开发领域，我们把这个概念称为“耦合度”和“内聚度”，这两个度量概念非常重要。

• 耦合度：指的是软件模块之间相互依赖的程度。比如，每次调用方法 A 之后都需要同步调用方法 B，那么此时方法 A 和 B 间的耦合度是高的。
• 内聚度：指的是模块内的元素具有的共同点的相似程度。比如，一个类中的多个方法有很多的共同之处，都是做支付相关的处理，那么这个类的内聚度是高的。

内聚度通常与耦合度形成对比。低耦合通常与高内聚相关，反之亦然。所以，当你打算进行分治的时候，耦合度和内聚度就是需要考虑的重点。

冗余

这里的冗余并不等同于代码的冗余、无意义的重复劳动，而是我们有意去做的、人为增加的重复部分。其目的是容许在一定范围内出现故障，而系统不受影响。
但是，单纯地为了备用而做的冗余，最大的弊端是，如果没有出现故障，那么冗余的这部分资源就白白浪费了，不能发挥任何作用。所以，我们才提出了诸如双主多活、读写分离之类的概念，以提高资源利用率。
不过也很显然，当故障影响范围大于你冗余的容量时，系统依然会挂。所以，既然你无法预知故障的发生情况，那么做冗余的时候需要平衡的另一端就是成本。相比更多的冗余，追求更好的性价比更合理一些。

再连接

分治和冗余讲究的都是分散化，最终形成一个完整的系统还需要将它们“连接”起来。天下没有免费的午餐，获得分布式系统价值的同时，这个“再连接”的过程就是我们相比集中式系统要做的额外工作。
如何将拆分后的各个节点再次连接起来，从模式上来说，主要是去中心化与中心化之分。
前者完全消除了中心节点故障带来的全盘出错的风险，却带来了更高的节点间协作成本。后者通过中心节点的集中式管理大大降低了协作成本，但是一旦中心节点故障则全盘出错。
另外，从技术角度来说，如何选择通信协议和序列化机制，也是非常重要的。
虽然很多通讯协议和序列化机制完全可以承担任何场景的连接责任，但是不同的协议和序列化机制在适合的场景下才能发挥它最大的优势。比如，需要更高性能的场景运用 TCP 协议优于 HTTP 协议；需要更高吞吐量的场景运用 UDP 协议优于 TCP 协议，等等。

事物最本质的东西是恒定的、不变的，可以指引我们的工作方向。分布式系统的本质也是这样。
例如，这样的“分治”方案耦合度和内聚度是否最优，这样做“冗余”带来的收益是否成本能够接受。只要持续带着这些思考，我们就好像拿着一杆秤，基于它，我们就可以去衡量各种变量影响，然后作权衡。比如成本、时间、人员、性能、易维护等等。也可以基于它去判断什么样的框架、组件、协议更适合当前的环境。
需要不断的权衡，也意味着分布式系统的设计工作一定不是一步到位，而是循序渐进的。因为过分为未知的未来做更多的考量，最终可能都会打水漂。所以，建议以多考虑 1~2 步为宜。假如以你所在的团队中对重大技术升级的频率来作为参考的话，做可供 2 个升级周期的设计，花一个升级周期的时间先实现第一阶段，下个阶段可以选择直接实现剩下部分，也可继续进行 2 个升级周期设计，开启一个循环，持续迭代，并且不断修正方向以更贴近现实的发展，就如下图这样。

分布式系统中最容易被忽视的坑

1.网络并不是可靠的

需要在系统设计中，尽可能地考虑到：**当前节点所依赖的其他节点由于各种原因无法与之正常通信时，该如何保证其依然能够提供部分或者完整的服务。**这个概念在软件领域被定义为“鲁棒性”。

2.不同节点之间的通信是存在延迟的

我们不能以调用本地方法一样的认知去理解远程调用（RPC）。在目前的技术环境下，CPU 的运算能力长期保持高速增长，因此两个节点间通讯的大部分场景中，延迟的耗时总是大于目标节点进行逻辑运算的耗时。
由此可得，并不是将一个集中式系统拆分得越散，系统就越快。当中存在的延迟，不容忽视。

我们还需要慎重考虑是否有必要进行“同步”的 RPC 调用，以及尽量的降低调用次数等。这就是为什么我们说，循环调用不如一次批量调用，反复调用不如调用一次做进程内缓存 的道理。

3.带宽是有上限的

• 实际环境中的传输速率大小，是由服务商所提供的带宽大小，以及网卡、网卡、交换机、路由器所支持的传输速率中的最小值决定的。

• 内网与外网传输速率是不同的，一般都是内网大于外网。因为服务商所提供的带宽成本更高。
• 同一个局域网内的节点是公用外网出入口的，所以尽可能的缩小在外网传输的数据，以降低占用“独木桥”外网的空间。

4.分布式并不直接意味着是“敏捷”了

拆分后需要做的额外工作如果没做好，可能会导致不是更快，而是更慢。最典型的现象如：

• 发布更麻烦了
• 排查问题更难了

关于这点，你需要秉持着工欲善其事必先利其器的思想。将建设协作相关的辅助性工作与分布式系统同时进行。比如：监控告警系统、配置中心、服务发现，以及批量部署、持续集成，甚至 DevOps 等。

5.数据由一份冗余成多份后如何保持一致

这个概念在软件领域被定义为「数据一致性」。

6.整个系统的不同部分可能是异构的

形容一个包含或者组成“异构网络”的产品，所谓的“异构网络”通常指不同厂家的产品所组成的网络。

在系统初期，同类技术下的差异往往不太被关注。但是随着分布式系统规模的逐渐扩大，在进入到成熟期的过程中，往往不可避免的会使系统成为异构的，有主动的，也有被动的。
关于这点，你要思考如何通过专制的方式进行标准化，来屏蔽这些差异带来的复杂度影响，使得有更多的精力投入到有价值的地方去。专制的特点是“约束”效果，标准化通过专制来进行可以降低许多为了方便而妥协问题。比如每个节点都通过统一的远程调用（RPC）中间件来做“连接”，就将如何连接异构节点的问题交由这个中间件来全权负责，而不是不同的团队各自实现一套。

双重校验锁实现单例

/**
 * 双重校验锁实现单例
 */
public class Singleton {
    private static volatile Singleton instance;
    
    // 私有构造方法
    private Singleton() {}
   
    // 双重校验锁
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

web.xml 中 Filter 执行顺序

1）先执行带有url-pattern标签的filter，再执行带有servlet-name标签的filter。

<filter-mapping>
    <filter-name>AppRequest1</filter-name>
    <url-pattern>*.do</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>AppRequest2</filter-name>
    <servlet-name>SomServlet</servlet-name>
</filter-mapping>

2）如果同为url-pattern或servlet-name，则会按照在web.xml中的声明顺序执行。

https

CA 无法对整个报文进行加密，因为非对称加密的内容长度不能比公钥长，因此才生成一个摘要，对摘要进行加密。一个故事讲完https 黑客攻防日记

先删数据库再删缓存

在论坛上看到好多人说先删除缓存在更新数据库，这种逻辑是错误的，

第一种情况 先删缓存在删数据库：在多线程环境下，当一个线程把缓存删掉之后，另一个线程都缓存，都不到缓存就会直接读库，读到数据后就会更新缓存，先前的线程呢，才更新数据库，会造成缓存脏读的情况，很容易产生缓存脏读。

第二种情况 先删数据库再删缓存：在多线程情况下，当一个线程删除数据库，另一个线程读取缓存数据，读到的是缓存的数据，当先前一个线程删完数据库后就会更新缓存，这是缓存就正常了，产生了一次脏读。

分析对比：
1.第一种产生了长时间的脏读，第二种只有很短时间的脏读 2.第一种删除缓存后会造成缓存击穿，如果大量线程访问就会中造成数据库压力过大，第二种其他线程会读取缓存数据，不会对数据库造成很大压力，更新数据库后缓存马上就更新了。

尾递归

当递归调用是函数体中最后执行的语句并且它的返回值不属于表达式一部分时， 这个递归就是尾递归。
现代的编译器就会发现这个特点， 生成优化的代码， 复用栈帧。 (张大胖学递归)[https://mp.weixin.qq.com/s/YpG9TvTCBus2FK6LbArvvw]

函数式编程圣经

要有不变量；函数应该是纯粹的（纯函数）； 要有递归； 要有高阶函数

定期整理简历

到了年末才整理简历，去做总结有点晚了， 应该在每个项目结束以后就去整理，时刻提醒自己：要有成长，不能原地踏步。对于没入行的人来讲，简历上要有项目经验，对于已经工作了的人来说，简历上应该有==亮点==。

黑客精神

据说每个程序员内心都有一个黑客梦，其实攻击者那叫骇客（Cracker），只要你有一颗不被束缚的心，你就是黑客（Hacker）

H5 首屏优化

前端优化 webview 池 客户端缓存 离线包 缓存/预加载/并行

Docker 镜像

简单来说 Docker 镜像中没有内核，Docker 镜像中程序共享宿主机内核 图片来自：Docker镜像和VM镜像

Elasticsearch 聚合中的重要概念 - Buckets(桶)及Metrics(指标)

一个桶就是满足特定条件的一个文档集合：

• 一名员工要么属于男性桶，或者女性桶。
• 城市Albany属于New York州这个桶。
• 日期2014-10-28属于十月份这个桶。

桶能够让我们对文档进行有意义的划分，但是最终我们还是需要对每个桶中的文档进行某种指标计算。分桶是达到最终目的的手段：提供了对文档进行划分的方法，从而让你能够计算需要的指标。

多数指标仅仅是简单的数学运算(比如，min，mean，max以及sum)，它们使用文档中的值进行计算。
一个聚合就是一些桶和指标的组合。一个聚合可以只有一个桶，或者一个指标，或者每样一个。在桶中甚至可以有多个嵌套的桶。 很久之前，对于磁盘的了解，就知道一个很关键的指标MTBF，即相邻两次故障之间的平均工作时间，也称为平均故障间隔，这个值越大越好，越大意味着硬盘更不容易坏。 对于RAID，也是很相信，觉得大多数情况下，使用RAID，就能保证数据的安全性，几乎不会有数据丢失的风险。

Unrecoverable Read Error Rate (URE)

突然的，读到一篇对于RAID 6的文章 Why RAID 6 stops working in 2019，这是一篇2010年的文章，很遗憾到目前才读到。 这篇文章里提到了一个指标，叫URE，也就是Unrecoverable Read Error Rate，不可恢复读取错误，一般普通的桌面级别硬盘，这个指标的值为1 × 10^-14，意味着每读取10^14bit的数据，就有可能产生1bit的错误。

问题在于，这个错误是无法被检测和修复的。10^14bit，大约相当于12.5TB的数据，也就是说，每读取12.5TB的数据，就有可能产生一个错误的读取。而对于目前现在硬盘的容量越来越大，4TB，6TB硬盘的价格越来越低，这种现象会越来越严重。

在RAID5中，当整个集群有一块硬盘出现损坏需要替换时，需要进行重建，重建时，需要读取其他硬盘的数据，计算出替换的那块硬盘的数据，在重建过程中，除了需要考虑重建的时间之外，还要考虑的就是URE的影响，如果集群的容量足够大，比如超过10TB，那么，其实是有很大的概率出现读取错误的，而一旦读取出错，则RAID的重建就会失败，基本也就意味着，数据能恢复的可能性变得相当低了。所以在使用RAID5时，就需要考虑重建的问题。

不过对于企业级的硬盘，URE普遍能做到1×10^-15，就意味着大约能读取125TB的数据，容量有比较大的提升，对于SSD，这个值会更加优秀，有些SSD能达到1×10^-17甚至1×10^-18，能提供更好的数据安全性。

所以，稳定点的话，还是RAID10吧。

RAID10 VS RAID01

• RAID10是先做镜象，然后再做条带。
• RAID01则是先做条带，然后再做镜象。

RAID10比RAID01在==安全性方面要强==。从数据存储的逻辑位置来看，在正常的情况下RAID01和RAID10是完全一样的，而且每一个读写操作所产生的IO数量也是一样的，所以在==读写性能上两者没什么区别==。而当有磁盘出现==故障==时，在读的性能上面也将不同，RAID10的读性能将==优于RAID01==。

RAID5 典型的存储选择是 2D+1P、4D+1P、8D+1P。

• D 指数据块（data）
• P 指校验块（parity）

aspose 转码命令

。。。。。

ImageMagick 安装依赖的主要类库

yum install libpng libpng-devel libtiff libtiff-devel libjpeg-turbo libjpeg-turbo-devel zlib