[半转载]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/dubbo/dubbo-call-flow.html

概要精简版流程

1. 客户端从注册中心拉取和订阅服务列表
2. 聚合服务列表，形成Invoker
3. 客户端通过路由和负载均衡选择合适的服务提供者
4. 将请求交给底层的I/O线程池处理
5. 在I/O线程池中进行序列化和反序列化等操作
6. 将请求交给业务线程池处理业务方法调用
   Dubbo的调用流程主要在客户端完成，通过注册中心、路由、负载均衡等机制实现服务的发现和选择，然后通过底层的I/O线程池和业务线程池处理请求。这样的设计使得Dubbo具备高性能、高并发的特点，适用于分布式系统中的服务调用场景。

补充版流程

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/MQ/mq-kafka.html

1. 为什么 Kafka 快

1.1 通过生产和缓冲区减少网络开销

Kafka 的生产者发送消息时，会将多条消息打包为一个 batch（发送缓冲区）一起发送，等缓冲区大小达到阈值或者一定时间，批量发送，从而减少网络开销

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/MQ/mq-rabbitmq.html

RabbitMQ是一款开源的消息中间件，采用AMQP（高级消息队列协议）作为底层协议，提供了可靠的消息传递机制、灵活的路由方式以及多种消息发布/订阅模式等特性，被广泛应用于分布式系统、微服务架构等场景中

数据发布方式

RabbitMQ支持多种消息发布方式，主要包括以下几种：

1. P2P（点对点）模式

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/system/IO-model2.html

接: IO模型

Java I/O模型与系统I/O模型的映射关系

Java的I/O模型是建立在底层系统I/O模型之上的，它通过对底层系统I/O调用的封装，提供了更高层次的抽象和统一的I/O接口。Java的I/O类库支持的I/O模型和底层系统I/O模型之间的映射关系如下：

1. 阻塞式I/O模型

   Java的I/O类库默认使用阻塞式I/O模型。在该模型下，I/O操作会一直阻塞，直到数据准备好或者操作完成才返回。对应的系统I/O模型是传统的阻塞式I/O模型。主要对应的系统I/O模型是Linux系统中的read(), write()

   这里主要是各种Stream、Reader、Writer、Socket的读写，其中Socket为：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14

   ServerSocketChannel serverSocketChannel = ServerSocketChannel.open(); // 监听 8080 端口进来的 TCP 链接 serverSocketChannel.socket().bind(new InetSocketAddress(8080)); while (true) { // 这里会阻塞，直到有一个请求的连接进来 SocketChannel socketChannel = serverSocketChannel.accept(); // 开启一个新的线程来处理这个请求，然后在 while 循环中继续监听 8080 端口 SocketHandler handler = new SocketHandler(socketChannel); new Thread(handler).start(); }

2. 非阻塞式I/O模型

   Java的I/O类库可以使用非阻塞式I/O模型。在该模型下，I/O操作会立即返回，不会阻塞，但此时数据可能还没有准备好或者操作没有完成。需要使用轮询的方式检查操作是否完成。对应的系统I/O模型是非阻塞式I/O模型。主要对应的系统I/O模型是Linux系统中的select()或poll()函数
   java中主要是通过selector轮询socket的事件：

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/system/IO-model.html

背景

服务器网络模型
这篇IO模型是《每天进步一点点》里的第一篇学习记录，真的是忘了看看了忘了。。其实不用记服务器的，大概理一下JAVA自己的就简单多了，这里稍微总结一下：

JAVA IO模型

JAVA的IO模型分为BIO、NIO、AIO三种，其中BIO是阻塞IO，NIO是非阻塞IO，AIO是异步IO

[转载]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/framework-design/sec-kill-framework-design.html

常见的三类高并发场景

高并发压力主要来自,并发时出现大量锁冲突

1.细颗粒度操作-锁冲突少 如:QQ微信等即时通讯业务个人读个人自己的数据

数据结构

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/es-structure-optimization.html

今天来介绍一个不错的优化：

背景

因为我们对订单的ES索引模板中，orderExtendInfoList存储多个扩展属性，用作外部订单号、二程运单号等信息的存储，业务上需要对其作为条件进行索引，为此我们把他设置为嵌套nested类型。
偶然学习发现这种嵌套nested类型会导致每个订单下的orderExtendInfo都会生成多个文档，导致索引数据量放大几倍，会导致查询性能下降，故重新设计进行优化。

优化ES存储订单数据的结构

参考主要来自58沈剑←
[知识整理]根据个人理解整理后分享，请批判接受，有误请指正。转载请注明出处:
https://heyfl.gitee.io/design/Weibo-feed-design.html

什么是Feed流

Feed流即持续更新并呈现给用户内容的信息流 , 对于微博.微信朋友圈等业务刷新的数据都为Feed流
每条微博 朋友圈 为一条Feed

关键动作,关键数据

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/Kafka-Delay-Queue.html

s

目前在用方案:直接重新丢回队列后面

实现逻辑

[转载]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/Spring/Spring-events.html

• ContextRefreshedEvent：表示ApplicationContext已经初始化或刷新完成时触发。通常在应用程序启动时使用，用来执行初始化操作
• ContextStartedEvent：表示ApplicationContext已经启动时触发。通常在应用程序启动时使用，用来执行一些启动任务
• ContextStoppedEvent：表示ApplicationContext已经停止时触发。通常在应用程序停止时使用，用来执行一些清理任务
• ContextClosedEvent：表示ApplicationContext已经关闭时触发。通常在应用程序关闭时使用，用来执行一些清理任务
• RequestHandledEvent：表示Web请求已经处理完成时触发。通常在Web应用程序中使用，用来记录日志或统计数据
• ApplicationStartedEvent：表示Spring Boot应用程序已经启动完成时触发。通常在Spring Boot应用程序中使用，用来执行启动任务
• ApplicationReadyEvent：表示Spring Boot应用程序已经准备就绪时触发。通常在Spring Boot应用程序中使用，用来执行一些初始化任务
• ApplicationFailedEvent：表示Spring Boot应用程序启动失败时触发。通常在Spring Boot应用程序中使用，用来执行一些异常处理任务