前一篇文章:《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),不仅对数据进行了加密,还对数据完整性提供了保护。
联系客服