java小结3.22

ping命令主要基于ICMP（Internet Control Message Protocol）实现，它包含了两部分：客户端、服务器。

客户端：向服务端发送ICMP回显请求报文（echo message）。

服务端：向客户端返回ICMP回显响应报文（echo reply message）

ping命令是用来探测主机到主机之间是否可通信，如果不能ping到某台主机，表明不能和这台主机建立连接。ping命令是使用 IP 和网络控制信息协议 (ICMP)，因而没有涉及到任何传输协议(UDP/TCP) 和应用程序。它发送icmp回送请求消息给目的主机。

ICMP协议规定：目的主机必须返回ICMP回送应答消息给源主机。如果源主机在一定时间内收到应答，则认为主机可达。

在三种情况下可能会发生上下文切换：中断处理，多任务处理，内核/用户态切换。

在中断处理中，其他程序”打断”了当前正在运行的程序。当CPU接收到中断请求时，会在正在运行的程序和发起中断请求的程序之间进行一次上下文切换。

在多任务处理中，CPU会在不同程序之间来回切换，每个程序都有相应的处理时间片，CPU在两个时间片的间隔中进行上下文切换。

在Linux中进行内核/用户态切换也会进行上下文切换，进行系统调用时，CPU寄存器里原来用户态的指令位置需要先保存起来。接着，为了执行内核态代码，CPU寄存器需要更新为内核态指令的新位置。最后才是跳转到内核态运行内核任务。而系统调用结束后，CPU寄存器需要恢复原来保存的用户态，然后再切换到用户空间，继续运行进程，所以一次系统调用的过程，其实是发生了两次CPU上下文切换。

信号量Semaphore：信号量是一个计数器，可以用来控制多个进程对共享资源的访问。它常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段

域名的解析过程大概是这样的：

1. 主机向本地域名服务器的查询一般都是采用`递归查询`。递归查询的特点是：如果主机所询问的本地域名服务器不知道被查询域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其他根域名服务器继续发出查询请求报文，也就是代替主机继续查询。

2. 本地域名服务器向根域名服务器的查询通常是采用`迭代查询`。迭代查询的特点是：当根域名服务器收到本地域名服务器的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地域名服务器："你下一步应当向哪一个域名服务器进行查询。"。然后让本地域名服务器进行后续的查询。根域名通常将自己知道的顶级域名服务器的IP地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所查询的IP地址，要么告诉本地域名服务器下一步应当向哪一个 权限域名服务器进行查询，本地域名服务器就这样迭代查询，最后，直到了所要解析的域名的IP地址，然后把这个结果返回给发起查询的主机。当然本地域名服务器也可以采用递归查询来完成这个过程，不过这种方式用的较少。

假定域名为`http://m.xyz.com`的主机想知道另一个主机（`http://y.abc.com`）的IP地址，下面是采用上图a的几个查询步骤：

1. 主机http://mxyz.com先向其本地域名服务器http://dns.xyz.com进行 递归 查询
   2. 本地域名服务器采用迭代查询。它先向一个根域名服务器查询。
   3. 根域名服务器告诉本地域名服务器，下一次应查询的顶级域名服务器 http://dns.com的IP地址。
   4. 本地域名服务器向顶级域名服务器http://dns.com进行查询。
   5. 顶级域名服务器http://dns.com告诉本地域名服务器,下一次应查询的权限域名服务器http://dns.abc.com的IP地址。
   6. 本地域名服务器向权限域名服务器http://dns.abe.com进行查询。
   7. 权限域名服务器http://dns.abc.com告诉本地域名服务器，所查询的主机的IP地址。
   8. 本地域名服务器最后把查询结果告诉主机`http://m.xyz.com`。
   本地根顶级权限

DNS的缓存

为了提高DNS查询效率，在域名服务器中广泛地使用了高速缓存，每个域名服务器都维护一个高速缓存，存放最近用过的名字以及从何处获得名字映射信息的记录。这种策略可以大大减轻根域名服务器的负荷，使因特网上的DNS查询请求和回答报文的数量大为减少。

但同时为保持高速缓存中的内容正确，域名服务器应为每项内容设置计时器，并处理超过合理时间的项（例如，每个项目只存放两天）。当权限域名服务器回答一个查询请求时，在响应中都指明绑定有效存在的时间值。增加此时间值可减少网络开销，而减少此时间值可提高域名转换的准确性

当我们不想访问或者不能直接访问一个对象的时候，我们就需要用到代理模式。代理模式一般涉及到委托类与代理类两个概念，代理类用于为委托类处理一些事务，代理类对象常常与委托类对象相关联。

代理模式可以分为静态代理和动态代理，静态代理需要为每一个委托类实现一个代理类，程序运行之前代理类的.class文件就已经存在了，而动态代理则是在运行时利用反射机制动态生成的。

为了帮助大家看懂静态代理，我们举个简单的例子，小丽要买一只口红，但是这只口红在国内买不到，只有美国有得卖，这时就需要代购（代理）帮助小丽去美国买口红。我们尝试实现一下这个过程。

Apache Kafka是由Apache开发的一种发布订阅消息系统，它是一个分布式的、分区的和重复的日志服务。

传统的消息传递方法包括两种：

排队：在队列中，一组用户可以从服务器中读取消息，每条消息都发送给其中一个人。

发布-订阅：在这个模型中，消息被广播给所有的用户。

kafka的外在表现很像消息系统，允许发布和订阅消息流，但是它和传统的消息系统有很大的差异：

首先，kafka是个现代分布式系统，以集群的方式运行，可以自由伸缩

其次，kafka可以按照要求存储数据，保存多久都可以

第三，流式处理将数据处理的层次提示到了新高度，消息系统只会传递数据。kafka的流式处理能力可以让我们用很少的代码就能动态的处理派生流和数据集。所以，kafka不仅仅是个消息中间件

Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

abbitmq在金融场景中经常使用，具有较高的严谨性，数据丢失的可能性更小，同事具备更高的实时性；而kafka优势主要体现在吞吐量上，虽然可以通过策略实现数据不丢失，但从严谨性角度来讲，大不如rabbitmq；而且由于kafka保证每条消息最少送达一次，有较小的概率会出现数据重复发送的情况；

负载均衡集群运行时，一般通过一个或者多个前端负载均衡器，将工作负载分发到后端的一组服务器上，从而达到整个系统的高性能和高可用性。

kafka介绍

kafka是apache开源的消息队列顶级项目之一，在大数据场景下使用较多，由linkedin开源，目前社区活跃，全球较多组织开始使用kafka来进行数据交换。

rabbitmq介绍

RabbitMQ是流行的开源消息队列系统，用erlang语言开发。RabbitMQ是AMQP（高级消息队列协议）的标准实现。

实际场景选择

在实际生产应用中，通常会使用kafka作为消息传输的数据管道，rabbitmq作为交易数据作为数据传输管道，主要的取舍因素则是是否存在丢数据的可能；rabbitmq在金融场景中经常使用，具有较高的严谨性，数据丢失的可能性更小，同事具备更高的实时性；

而kafka优势主要体现在吞吐量上，虽然可以通过策略实现数据不丢失，但从严谨性角度来讲，大不如rabbitmq；而且由于kafka保证每条消息最少送达一次，有较小的概率会出现数据重复发送的情况；

1.应用场景方面

RabbitMQ：用于实时的，对可靠性要求较高的消息传递上。

kafka：用于处于活跃的流式数据，大数据量的数据处理上。

2.架构模型方面

producer，broker，consumer

RabbitMQ：以broker为中心，有消息的确认机制,更加安全

kafka：以consumer为中心，无消息的确认机制，严谨性较低

3.吞吐量方面

RabbitMQ：支持消息的可靠的传递，支持事务，不支持批量操作，基于存储的可靠性的要求存储可以采用内存或硬盘，吞吐量小。

kafka：内部采用消息的批量处理，数据的存储和获取是本地磁盘顺序批量操作，消息处理的效率高，吞吐量高。

4.集群负载均衡方面

RabbitMQ：本身不支持负载均衡，需要loadbalancer的支持

kafka：采用zookeeper对集群中的broker，consumer进行管理，可以注册topic到zookeeper上，通过zookeeper的协调机制，producer保存对应的topic的broker信息，可以随机或者轮询发送到broker上，producer可以基于语义指定分片，消息发送到broker的某个分片上。

Zookeeper 对于 Kafka 的作用是什么？

Zookeeper 是一个开放源码的、高性能的协调服务，它用于 Kafka 的分布式应用。

Zookeeper 主要用于在集群中不同节点之间进行通信

在 Kafka 中，它被用于提交偏移量，因此如果节点在任何情况下都失败了，它都可以从之前提交的偏移量中获取 除此之外，它还执行其他活动，如: leader 检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。

1.RabbitMQ的消息应当尽可能的小，并且只用来处理实时且要高可靠性的消息。

2.消费者和生产者的能力尽量对等，否则消息堆积会严重影响RabbitMQ的性能。

3.集群部署，使用热备，保证消息的可靠性。

1.应当有一个非常好的运维监控系统，不单单要监控Kafka本身，还要监控Zookeeper。(kafka强烈的依赖于zookeeper,如果zookeeper挂掉了，那么Kafka也不行了)

2.对消息顺序不依赖，且不是那么实时的系统。

3.对消息丢失并不那么敏感的系统。

4.从 A 到 B 的流传输，无需复杂的路由，最大吞吐量可达每秒 100k 以上。

讲一讲为什么Redis这么快？

首先，采用了多路复用io阻塞机制 处理大量客户端的Socket请求

然后，数据结构简单，操作节省时间

最后，运行在内存中，自然速度快

因为Redis的瓶颈不是cpu的运行速度，而往往是网络带宽和机器的内存大小。再说了，单线程切换开销小，容易实现既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。

并发性I/O流，意味着能够让一个计算单元来处理来自多个客户端的流请求

有序集合的内部实现有压缩列表（ziplist）和跳跃表（skiplist）两种，当集合中的所有元素的成员长度较短并元素个数较少时，使用 压缩列表 作为内部实现，否则使用跳跃表和哈希表作为内部实现。当条件不满足时，压缩列表可以转换为跳跃表，但跳跃表不能转换为压缩列表。

有序集合的内部实现有两种，分别是：压缩列表（ziplist）和跳跃表（skiplist）。接下来，我们分别进行详细的了解。

当有序集合的元素个数小于zset-max-ziplist-entries（默认为128个），并且每个元素成员的长度小于zset-max-ziplist-value（默认为64字节）的时候，使用压缩列表作为有序集合的内部实现。

当有序集合的元素个数大于等于zset-max-ziplist-entries（默认为128个），或者每个元素成员的长度大于等于zset-max-ziplist-value（默认为64字节）的时候，使用跳跃表作为有序集合的内部实现。

此时，在有序集合中其实包含了两个结构，一个是跳跃表，另一个是哈希表。

在跳跃表中，所有元素按照从小到大的顺序排列。跳跃表的结点中的object指针指向元素成员的字符串对象，score保存了元素的分数。通过跳跃表，Redis可以快速地对有序集合进行分数范围、排名等操作。

在哈希表中，为有序集合创建了一个从元素成员到元素分数的映射。键值对中的键指向元素成员的字符串对象，键值对中的值保存了元素的分数。通过哈希表，Redis可以快速查找指定元素的分数。

虽然有序集合同时使用跳跃表和哈希表，但是这两种数据结构都使用指针共享元素中的成员和分数，不会额外的内存浪费

哨兵(Sentinel)：可以管理多个Redis服务器，它提供了监控，提醒以及自动的故障转移的功能。哨兵是Redis集群架构中非常重要的一个组件，哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题。

Redis哨兵主要功能

（1）集群监控：负责监控Redis master和slave进程是否正常工作
（2）消息通知：如果某个Redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
（3）故障转移：如果master node挂掉了，会自动转移到slave node上
（4）配置中心：如果故障转移发生了，通知client客户端新的master地址

Redis哨兵的高可用(安全)

原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。