因为磁盘I/O很耗时，所以，I/O部分的总体优化原则是：

​ 能不磁盘I/O就不磁盘I/O，必须磁盘I/O就尽量顺序读取，且视情况实现并行I/O和异步I/O；

具体见下图：

Kafka：

Kafka的应用或者作用：

1. 提供流式数据，作为流式数据源；
2. 解耦/异步；
3. 洪峰处理（消峰，缓冲）；
4. 顺序性保证（单分区内是顺序性的）。

kafka里面对延时任务的处理，数据结构上采用了TimingWheel的形式，时间推进利用的是JDK里面的DelayQueue，具体见下图：

ZooKeeper

ZooKeeper 是一个开源的分布式协调服务，ZooKeeper框架最初是在“Yahoo!”上构建的，用于以简单而稳健的方式访问他们的应用程序。 后来，Apache ZooKeeper成为Hadoop，HBase和其他分布式框架使用的有组织服务的标准。 例如，Apache HBase使用ZooKeeper跟踪分布式数据的状态。ZooKeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

原语： 操作系统或计算机网络用语范畴。是由若干条指令组成的，用于完成一定功能的一个过程。具有不可分割性·即原语的执行必须是连续的，在执行过程中不允许被中断。

ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

ES： elastic search

ELK是Elasticsearch、Logstash、Kibana三大开源框架首字母大写简称。市面上也被成为Elastic Stack。其中Elasticsearch是一个基于Lucene、分布式、通过Restful方式进行交互的近实时搜索平台框架。像类似百度、谷歌这种大数据全文搜索引擎的场景都可以使用Elasticsearch作为底层支持框架，可见Elasticsearch提供的搜索能力确实强大,市面上很多时候我们简称Elasticsearch为es。Logstash是ELK的中央数据流引擎，用于从不同目标（文件/数据存储/MQ）收集的不同格式数据，经过过滤后支持输出到不同目的地（文件/MQ/redis/elasticsearch/kafka等）。Kibana可以将elasticsearch的数据通过友好的页面展示出来，提供实时分析的功能。

通过上面对ELK简单的介绍，我们知道了ELK字面意义包含的每个开源框架的功能。市面上很多开发只要提到ELK能够一致说出它是一个日志分析架构技术栈总称，但实际上ELK不仅仅适用于日志分析，它还可以支持其它任何数据分析和收集的场景，日志分析和收集只是更具有代表性。并非唯一性。

FTS:Full Text Seach 全文检索；

全文检索是从文本或数据库中，不限定数据字段，自由地搜索出消息的技术。

运行全文检索任务的程序，一般称作搜索引擎，它可以将用户随意输入的文字从数据库中找到匹配的内容。

移动端的实现方式：

iOS/Android SQLite全文检索——FTS (full text search) ,SQLite3或者4自带英文的分词器，但是如果处理中文的话，需要额外引入或者实现分词器；

Lucene

Lucene是apache下的一个开放源代码的全文检索引擎工具包（提供了Jar包，实现全文检索的类库）。它提供了完整的查询引擎和索引引擎，部分文本分析引擎。Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便地在目标系统中实现全文检索的功能。

注意：Lucene只是一个引擎，只是一个工具包，如果使用Lucene开发全文检索功能，要记住Lucene是不能单独运行的。

Lucene实现全文检索的流程

索引和搜索流程图

索引和搜索流程图如下：

ZeroCopy

ZeroCopy，或者叫零拷贝，是Linux里面的一个技术，支持零拷贝的系统调用是sendFile/mmap；这里说的零拷贝并不是真的一次都不需要拷贝，而是，避免了从内核态到用户态，和从用户态到内核态的无意义拷贝；Java中对零拷贝的支持，主要是NIO里面的FileChannel.transforTo()/FileChannel.transforFrom()/MappedByteBuffer;

近年来大火的Kafka，它的高效读写数据部分，也使用到了零拷贝；我们先看个kafka对零拷贝的使用的一个整体情况，见下图：

下面，我们详细介绍相关的情况；

DMA

DMA出现之前，各种数据传输工作都需要CPU，特别浪费。但是，实际上，这些数据传输工作用不到多少CPU核新的“计算”功能。另一方面，CPU的运转速度也比I/O操作要快很多，所以，导致CPU资源又被IO阻塞，又是阻塞在了没有太大意义的事上。

后来，抱着“希望能够给CPU“减负”的想法，工程师们就在主板上加上了DMAC这样一个协处理器芯片，通过这个芯片，CPU只需要告诉DMAC，我们要传输什么数据，从哪里来，到哪里去，就可以放心离开了。后续的实际数据传输工作，都会由DMAC来完成。随着现代计算机各种外设硬件越来越多，光一个通用的DMAC芯片不够了，我们在各个外设上都加上了DMAC芯片，这样，就使得CPU很少再需要关注数据传输的工作了。

在我们实际的系统开发过程中，利用好DMA的数据传输机制，也可以大幅提升I/O的吞吐率。最典型的例子就是Kafka。

读取数据并发送到网络

普通的方式和使用零拷贝技术的对比

​ 首先看下普通的读取数据并发送到网络的操作，实际底层执行时对应的动作：

​ 例如，我们的实现是 读取文件，再用socket发送出去，那么，我们使用传统方式实现时，大致要经过如下过程：

​ 先读取、再发送，实际经过1~4四次copy。

1、第一次：将磁盘文件，读取到操作系统的内核缓冲区（DMA）；

2、第二次：将内核缓冲区的数据，copy到application应用程序的buffer（用户空间【内存】）（CPU）；

3、第三步：将application应用程序buffer中的数据，copy到socket网络发送缓冲区(内核空间【内存】)（CPU）；

4、第四次：将socket buffer的数据，copy到网卡，由网卡进行网络传输（DMA）。

然后，我们下面再看下使用零拷贝（sendFile/ Java：FileChannel.transforTo() ）之后的流程：

我们会发现，使用了零拷贝之后，不再需要CPU拷贝了，原来的CPU拷贝的流程都省去了。

使用了零拷贝方法后，传输同样数据的时间，可以缩减为原来的1/3，也就是提升了3倍的吞吐率。

接收数据并写入到磁盘

这里我们就不再详细介绍普通的接收数据写入到磁盘的方式了，直接介绍下mmap的原理：

mmap （** Memory Mapped Files** ）是一种内存映射技术，可以将文件或对象映射到进程的内存地址空间，使得进程就像操作内存一样实现了“直接”对文件的高效读写。本质上来讲， mmap 实现的是内核缓冲区与用户进程的地址空间的映射，也就是说用户进程通过操作自己的逻辑虚拟地址就可以实现操作内核空间缓冲区，这样就不用再因为内核空间和用户空间相互隔离而需要将数据在内核缓冲区和用户进程所在内存之间来回拷贝。

** 通过mmap，进程可以像读写硬盘一样读写内存（当然是虚拟内存），使用这种方式可以获取很大的I/O提升，省去了用户空间到内核空间复制的开销。**

** mmap也有一个很明显的缺陷——不可靠，写到mmap中的数据并没有被真正的写到硬盘，操作系统会在程序主动调用flush的时候才把数据真正的写到硬盘。Kafka提供了一个参数——producer.type来控制是不是主动flush；如果Kafka写入到mmap之后就立即flush然后再返回Producer叫同步(sync)；写入mmap之后立即返回Producer不调用flush叫异步(async)。**

当然，Kafka之所以成为了实时数据传输管道的标准解决方案，或者说kafka的快速，也还与它使用磁盘的顺序读写有关；

顺序读写

我们简单说下是否顺序读写的对比：

磁盘顺序读或写的速度400M/s，能够发挥磁盘最大的速度。随机读写，磁盘速度慢的时候可能才十几到几百K/s。

kafka将来自Producer的数据，顺序追加在partition，partition就是一个文件，以此实现顺序写入。Consumer从broker读取数据时，因为自带了偏移量，接着上次读取的位置继续读，以此实现顺序读。顺序读写，也是kafka利用磁盘特性的一个重要方面；

为什么顺序读写更快呢？因为，顺序读写，可是充分利用CPU的预读，以及 可以避免写入放大效应；当然，还有就是一些寻址上的简化了。

除了平时提的最多的这6个设计原则之外，平时提的最多的一个设计原则就是 【组合/聚合复用原则】 ；

组合/聚合复用原则 ：面向对象的程序设计中，我们经常说“优先考虑使用组合来扩展类的功能，而不是使用继承，例如 代理模式、装饰器模式、适配器模式等设计模式”，这就是组合复用原则的应用；

注意：加载、验证、准备、初始化、卸载，这几个过程并不是完成一个之后再开始另一个，而是仅仅按照这个顺序开始~~

这里只针对Java中的线程安全问题的“需求”来源以及各种需求下的处理方式做一个梳理；因为这里没办法通过区区的一个思维导图的概括就把所有内容和所有情况涵盖进来，所以，很多线程安全问题都要具体问题再具体分析；

推荐一个内容质量较高的网站：并发编程网

Linux内核：

Linux中的文件系统概览如下：

Linux中的内存部分如下：

Android中的Low-memory killer 是Linux内核中原来就有的；

另外，由于Android中去掉了内存交换这部分，改用了内存压缩区，所以，在内存达到内存水位线触发kswapd后的处理和Linux中有一些不同；

Http基础原理

目的是对https和相关依赖的安全技术 有一个概括的认识，在判断一些事儿的时候头脑更清晰。 由于是基础理论方面的，都是理论，所以并没有太多代码相关的。 大家如果觉得自己的理解与我所描述的不同，非常欢迎提出来，我们一起确认下。

内容目录：

为什么？ 内容 对称加密 非对称加密 散列函数 （Base64编码） 数字签名 数字证书

​ Pinning

​ 开发中的常见错误写法

为什么？

回答一部分同学心里的如下的问题：

与使用http相比，使用https之后会有哪些好处？ 证书是什么？ QA：Https的抓包要怎么抓？为什么？ 贝勒爷：平时上一些“非正规网站”（比如xxx网【12306有进步了】）有的那个警告提示，点了“确定，继续前往” 意味着什么？ 开发：为什么有时候会遇到证书校验失败？ 少见的：为什么有时候我们也会遇到，明明我们已经把证书的签发者加到信任列表了，一些三方支付sdk的请求还是失败？

对于开发同学，各种资讯、博客、博客上的理解 等 整体的现状很残酷：

之前遇到的一些问题：

1. 发到play上的app，下架；
2. App（手机令牌）版本发现部分2.x的手机上出现证书无法验证通过。
3. 一些大陆版app的实现的问题

其他： 博客上随处可见的错误导向： http://zhidao.baidu.com/link?url=uYegvR3uuNuwlkpkNwZhgNZBgJUGQpE_0UGEg9ynV_aRkYJM_685K-d9ro3tTH9JFhXx5mL19-aA30qLYlzrVa http://drops.wooyun.org/tips/3296

乌云上的报告：国内绝大部分Android APP存在信任所有证书漏洞 http://www.wooyun.org/bugs/wooyun-2014-079358

以及 之前一篇论文指出，在Google Play 上 13500 个免费热门应用程序当中，共有 1074 个 (8%) 应用程序因错误的 SSL 处理而导致使用者陷入 MITM攻击【中间人攻击】的风险中。

对称加密：（私钥加密）

一种加密算法，加密与解密使用同一个密钥。

对称加密是依照19世纪一位密码破解专家Auguste Kerckhoffs的观察结果而来的： 即使攻击者知晓了整个密码系统除密钥外的所有情报，系统仍然应当能保证安全。

如果加密算法优秀，攻击者只有一种方法，就是尝试所有可能的解码密钥，俗称穷举密钥搜索。基于此，密文的安全性完全取决于密钥，主要就是密钥长度（当然，还要假设密钥本质上是随机的）。128位的密钥，有34*1037种可能的组合。

常见的对称加密算法有：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES

对称加密大规模应用的问题：

随着使用对称加密的团体的增加，产生了更多的无法满足的需求： 1. 相同团体的成员必须共享相同的密钥，越多人加入，团体密钥出现问题的次数就越多。 2. 为了更好的安全性，可以在每两个人之间使用不同的密钥，但是这个方法不可扩展，虽然3个人只需要3个密钥，但是10个人就需要45个密钥，1000个人就需要499500个密钥！ 3. 对称加密不能用于访问安全数据的无人系统，因为使用相同的密钥可以反转整个过程，系统出现任何问题都会影响存储在系统中的所有数据。

非对称加密

非对称加密：又称为公钥加密。不同于对称加密，非对称加密使用两个密钥，而不是一个；其中一个密钥是私密的，用于私人，另一个是公开的，将会被所有人共享。

两个密钥之间存在一些特殊的数学关系，使得： 利用公钥加密的数据，只有对应的私钥能够解密 。 （机密性） 如果用私钥加密数据，那么，任何人都可以利用对应的公钥解开消息。（这种操作不具有机密性，但可以用作数字签名。）

RSA是目前最普遍使用的非对称加密算法，现在推荐的RSA强度是2048位（强度等同于112位的对称密钥）。

非对称加密的问题：

... read more