前一篇文章：《Java工程师修炼之道》读书笔记-Part 1
Logstash -- 多个独立的Agent 负责收集不同来源的数据，一个中心Agent 负责汇总和分析数据。Elasticsearch -- 用于存储最终的数据，并提供搜索功能。Kibana -- 提供一个简单、丰富的Web 界面，数据来自 Elasticsearch，支持各种查询、统计和展示。
还可以在远程Logstash 和中心 Logstash 之间加入 Redis、Kafka等中间层，作为缓冲和中间存储，提高系统性能和可靠性。
(1) RESTful
RESTful 基于HTTP协议，主要依赖于HTTP协议的集中method来表示CRUD操作；RESTful 使用HTTP URL 标识并定位一个资源；原则上只使用名词来指定资源，而且推荐使用复数；URL 大小写敏感，尽量使用小写字母；
(2) RPC
RPC主要依赖的技术：序列化、反序列化和数据传输协议；Java使用比较多的RPC方案有：RMI、Hessian、Dubbo以及Thrift等；
(3) 消息中间件
消息队列的二手应用场景
解耦最终一致性广播错峰与流控
消息模型：
队列 P2P发布/订阅 pub/sub
消息中间件
(1) ActiveMQ
性能较差，不推荐在大规模互联网应用中使用；
(2) RabbitMQ
基于AMQP协议，是一个完备的消息中间件；适用于可靠性要求较高，对消息有事务要求的业务场景。只能保证At Least Once（消息至少被消费一次）的消费，无法从自身进行消息去重。如果要达到Exactly Once（消息会且仅会消费一次），应该由业务做去重处理，或者业务消息本身就具有幂等性。
(3) Kafka
基于文件append，以顺序读/写的方式来写入/读取文件，性能非常高，支持多订阅者。Kafka 设计的初衷是处理日志，因此是允许消息丢失的，对事务的支持也不好，并不能保证消息的顺序。Kafka 适用于海量消息场景，允许极端情况下少量丢失数据。一个Topic 可以分为多个Partition，每个Partition 内部是消息有序的。由于分区的原因，Kafka 无法保障全局消息有序，但是使用只有一个分区的Topic时，可以保证消息全局有序。
关于Kafka 深度分析文章，可参考：
Kafka设计原理，为什么Kafka性能高？如何保证Kafka不丢消息？
阻塞和非阻塞
是函数/方法的实现方式，即在数据就绪之前，是立刻返回还是等待。也就是发起 I/O 请求是否会被阻塞。
一个网络 I/O 读过程是：数据从网卡 -> 内核缓冲区 -> 用户内存的过程。
同步和异步
区别主要在于：数据从内核缓冲区到用户内存的这个过程，需要不需要用户进程等待。也就是实际的 I/O 读写是否阻塞请求进程。
阻塞 I/O 模型 - BIO
非阻塞 I/O 模型 - AIO
异步 I/O 模型 - AIO
JVM 内存模型屏蔽了底层硬件环境的差异，给Java应用程序提供了统一的内存访问模式，可以认为是一种虚拟内存环境。
在Java程序中，所有线程都共享主内存（堆），但是对于每一个线程都有自己的工作内存（一个虚拟的概念，包括寄存器、栈、写缓存、缓存以及其他硬件、编译器优化等）。
工作内存和主内存（堆）通过一些规定的操作来交互同步数据，而线程只能访问自己的工作内存。
主内存就是堆，用来保存对象信息；
工作内存就是栈，用来保存线程私有的对象地址、基本类型、局部变量、PC指针等信息；
SSL: (Secure Socket Layer，安全套接字层）
TLS: (Transport Layer Security，传输层安全协议)
SSL和 TLS 都是用于保障端到端之间连接的安全性，位于应用层和传输层之间。
SSL 现在已经改名为 TLS。
HTTPS 相比 HTTP 多了一个安全加密层（TLS/SSL），不仅对数据进行了加密，还对数据完整性提供了保护。
联系客服
