AI 助理
备案控制台
开发者社区 阿里技术 文章 正文

如何用Netty写一个高性能的分布式服务框架？

2021-06-22 8583
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： Netty 是一个致力于创建高性能网络应用程序的成熟的 IO 框架。相比较与直接使用底层的 Java IO API，不需要先成为网络专家就可以基于 Netty 去构建复杂的网络应用。业界常见的涉及到网络通信的相关中间件大部分基于 Netty 实现网络层。

image.png

作者 | 家纯
来源 | 阿里技术公众号

一 什么是 Netty? 能做什么?

  • Netty 是一个致力于创建高性能网络应用程序的成熟的 IO 框架。
  • 相比较与直接使用底层的 Java IO API，你不需要先成为网络专家就可以基于 Netty 去构建复杂的网络应用。
  • 业界常见的涉及到网络通信的相关中间件大部分基于 Netty 实现网络层。

二 设计一个分布式服务框架

1 Architecture

image.png

2 远程调用的流程

  • 启动服务端(服务提供者)并发布服务到注册中心。
  • 启动客户端(服务消费者)并去注册中心订阅感兴趣的服务。
  • 客户端收到注册中心推送的服务地址列表。
  • 调用者发起调用，Proxy从服务地址列表中选择一个地址并将请求信息 <group，providerName，version>，methodName，args[] 等信息序列化为字节数组并通过网络发送到该地址上。
  • 服务端收到收到并反序列化请求信息，根据 <group，providerName，version> 从本地服务字典里查找到对应providerObject，再根据 <methodName，args[]> 通过反射调用指定方法，并将方法返回值序列化为字节数组返回给客户端。
  • 客户端收到响应信息再反序列化为 Java 对象后由 Proxy 返回给方法调用者。

以上流程对方法调用者是透明的，一切看起来就像本地调用一样。

3 远程调用客户端图解

image.png

重要概念：RPC三元组 <ID，Request，Response>。

PS: 若是 netty4.x 的线程模型，IO Thread(worker) —> Map<InvokeId，Future> 代替全局 Map 能更好的避免线程竞争。

4 远程调用服务端图解

image.png

5 远程调用传输层图解

image.png

6 设计传输层协议栈

协议头

image.png

协议体

1）metadata: <group，providerName，version>

2）methodName

3）parameterTypes[] 真的需要吗?

（a）有什么问题?

  • 反序列化时 ClassLoader.loadClass() 潜在锁竞争。
  • 协议体码流大小。
  • 泛化调用多了参数类型。

（b）能解决吗?

  • Java方法静态分派规则参考JLS <Java语言规范> $15.12.2.5 Choosing the Most Specific Method 章节。

（c）args[]

（d）其他：traceId，appName…

三 一些Features&好的实践&压榨性能

1 创建客户端代理对象

1）Proxy 做什么?

  • 集群容错 —> 负载均衡 —> 网络

2）有哪些创建 Proxy 的方式?

  • jdk proxy/javassist/cglib/asm/bytebuddy

3）要注意的：

  • 注意拦截toString，equals，hashCode等方法避免远程调用。

4）推荐的(bytebuddy)：

image.png

2 优雅的同步/异步调用

  • 先往上翻再看看“远程调用客户端图解”
  • 再往下翻翻看看 Failover 如何处理更好
  • 思考下如何拿到 future?

3 单播/组播

  • 消息派发器
  • FutureGroup

4 泛化调用

image.png

5 序列化/反序列化

协议 header 标记 serializer type，同时支持多种。

6 可扩展性

Java SPI：

  • java.util.ServiceLoader
  • META-INF/services/com.xxx.Xxx

7 服务级别线程池隔离

要挂你先挂，别拉着我。

8 责任链模式的拦截器

太多扩展需要从这里起步。

9 指标度量(Metrics)

10 链路追踪

OpenTracing

11 注册中心

12 流控(应用级别/服务级别)

要有能方便接入第三方流控中间件的扩展能力。

13 Provider线程池满了怎么办?

image.png

14 软负载均衡

1）加权随机 (二分法，不要遍历)

image.png

2）加权轮训(最大公约数)

image.png

3）最小负载

4）一致性 hash (有状态服务场景)

5）其他

注意：要有预热逻辑。

15 集群容错

1）Fail-fast

2）Failover

异步调用怎么处理?

  • Bad

image.png

  • Better

image.png

3）Fail-safe

4）Fail-back

5）Forking

6）其他

16 如何压榨性能(Don’t trust it，Test it)

1）ASM 写个 FastMethodAccessor 来代替服务端那个反射调用

image.png

2）序列化/反序列化

在业务线程中序列化/反序列化，避免占用 IO 线程：

  • 序列化/反序列化占用数量极少的 IO 线程时间片。
  • 反序列化常常会涉及到 Class 的加载，loadClass 有一把锁竞争严重(可通过 JMC 观察一下)。

选择高效的序列化/反序列化框架：

  • 如kryo/protobuf/protostuff/hessian/fastjson/…

选择只是第一步，它(序列化框架)做的不好的，去扩展和优化之：

  • 传统的序列化/反序列化+写入/读取网络的流程：java对象--> byte[] -->堆外内存 / 堆外内存--> byte[] -->java对象。
  • 优化：省去 byte[] 环节，直接 读/写 堆外内存，这需要扩展对应的序列化框架。
  • String 编码/解码优化。
  • Varint 优化：多次 writeByte 合并为 writeShort/writeInt/writeLong。
  • Protostuff 优化举例：UnsafeNioBufInput 直接读堆外内存/UnsafeNioBufOutput 直接写堆外内存。

3）IO 线程绑定 CPU

4）同步阻塞调用的客户端和容易成为瓶颈，客户端协程：

  • Java层面可选的并不多，暂时也都不完美。

image.png

5）Netty Native Transport & PooledByteBufAllocator：

  • 减小GC带来的波动。

6）尽快释放 IO 线程去做他该做的事情，尽量减少线程上下文切换。

四 Why Netty?

1 BIO vs NIO

image.png

2 Java 原生 NIO API 从入门到放弃

复杂度高

  • API复杂难懂，入门困。
  • 粘包/半包问题费神。
  • 需超强的并发/异步编程功底，否则很难写出高效稳定的实现。

稳定性差，坑多且深

  • 调试困难，偶尔遭遇匪夷所思极难重现的bug，边哭边查是常有的事儿。
  • linux 下 EPollArrayWrapper.epollWait 直接返回导致空轮训进而导致 100% cpu 的 bug 一直也没解决利索，Netty帮你 work around (通过rebuilding selector)。

NIO代码实现方面的一些缺点

1）Selector.selectedKeys() 产生太多垃圾

Netty 修改了 sun.nio.ch.SelectorImpl 的实现，使用双数组代替 HashSet 存储来 selectedKeys：

  • 相比HashSet(迭代器，包装对象等)少了一些垃圾的产生(help GC)。
  • 轻微的性能收益(1~2%)。

Nio 的代码到处是 synchronized (比如 allocate direct buffer 和 Selector.wakeup() )：

  • 对于 allocate direct buffer，Netty 的 pooledBytebuf 有前置 TLAB(Thread-local allocation buffer)可有效的减少去竞争锁。
  • wakeup 调用多了锁竞争严重并且开销非常大(开销大原因: 为了在 select 线程外跟 select 线程通信，linux 平台上用一对 pipe，windows 由于 pipe 句柄不能放入 fd_set，只能委曲求全用两个 tcp 连接模拟)，wakeup 调用少了容易导致 select 时不必要的阻塞(如果懵逼了就直接用 Netty 吧，Netty中有对应的优化逻辑)。
  • Netty Native Transport 中锁少了很多。

2）fdToKey 映射

  • EPollSelectorImpl#fdToKey 维持着所有连接的 fd(描述符)对应 SelectionKey 的映射，是个 HashMap。
  • 每个 worker 线程有一个 selector，也就是每个 worker 有一个 fdToKey，这些 fdToKey 大致均分了所有连接。
  • 想象一下单机 hold 几十万的连接的场景，HashMap 从默认 size=16，一步一步 rehash...

3）Selector在linux 平台是 Epoll LT 实现

  • Netty Native Transport支持Epoll ET。

4）Direct Buffers 事实上还是由 GC 管理

  • DirectByteBuffer.cleaner 这个虚引用负责 free direct memory，DirectByteBuffer 只是个壳子，这个壳子如果坚强的活下去熬过新生代的年龄限制最终晋升到老年代将是一件让人伤心的事情…
  • 无法申请到足够的 direct memory 会显式触发 GC，Bits.reserveMemory() -> { System.gc() }，首先因为 GC 中断整个进程不说，代码中还 sleep 100 毫秒，醒了要是发现还不行就 OOM。
  • 更糟的是如果你听信了个别<XX优化宝典>谗言设置了-XX:+DisableExplicitGC 参数，悲剧会静悄悄的发生...
  • Netty的UnpooledUnsafeNoCleanerDirectByteBuf 去掉了 cleaner，由 Netty 框架维护引用计数来实时的去释放。

五 Netty 的真实面目

1 Netty 中几个重要概念及其关系

EventLoop

  • 一个 Selector。
  • 一个任务队列(mpsc_queue: 多生产者单消费者 lock-free)。
  • 一个延迟任务队列(delay_queue: 一个二叉堆结构的优先级队列，复杂度为O(log n))。
  • EventLoop 绑定了一个 Thread，这直接避免了pipeline 中的线程竞争。

Boss: mainReactor 角色，Worker: subReactor 角色

  • Boss 和 Worker 共用 EventLoop 的代码逻辑，Boss 处理 accept 事件，Worker 处理 read，write 等事件。
  • Boss 监听并 accept 连接(channel)后以轮训的方式将 channel 交给 Worker，Worker 负责处理此 channel 后续的read/write 等 IO 事件。
  • 在不 bind 多端口的情况下 BossEventLoopGroup 中只需要包含一个 EventLoop，也只能用上一个，多了没用。
  • WorkerEventLoopGroup 中一般包含多个 EventLoop，经验值一般为 cpu cores * 2(根据场景测试找出最佳值才是王道)。
  • Channel 分两大类 ServerChannel 和 Channel，ServerChannel 对应着监听套接字(ServerSocketChannel)，Channel 对应着一个网络连接。

2 Netty4 Thread Model

image.png

3 ChannelPipeline

image.png

4 Pooling&reuse

PooledByteBufAllocator

  • 基于 jemalloc paper (3.x)
  • ThreadLocal caches for lock free：这个做法导致曾经有坑——申请(Bytebuf)线程与归还(Bytebuf)线程不是同一个导致内存泄漏，后来用一个mpsc_queue解决，代价就是牺牲了一点点性能。
  • Different size classes。

Recycler

  • ThreadLocal + Stack。
  • 曾经有坑，申请(元素)线程与归还(元素)线程不是同一个导致内存泄漏。
  • 后来改进为不同线程归还元素的时候放入一个 WeakOrderQueue 中并关联到 stack 上，下次 pop 时如果 stack 为空则先扫描所有关联到当前 stack 上的 weakOrderQueue。
  • WeakOrderQueue 是多个数组的链表，每个数组默认size=16。
  • 存在的问题：思考一下老年代对象引用新生代对象对 GC 的影响？

5 Netty Native Transport

相比 Nio 创建更少的对象，更小的 GC 压力。

针对 linux 平台优化，一些 specific features：

  • SO_REUSEPORT - 端口复用(允许多个 socket 监听同一个 IP+端口，与 RPS/RFS 协作，可进一步提升性能)：可把 RPS/RFS 模糊的理解为在软件层面模拟多队列网卡，并提供负载均衡能力，避免网卡收包发包的中断集中的一个 CPU core 上而影响性能。
  • TCP_FASTOPEN - 3次握手时也用来交换数据。
  • EDGE_TRIGGERED (支持Epoll ET是重点)。
  • Unix 域套接字(同一台机器上的进程间通信，比如Service Mesh)。

6 多路复用简介

select/poll

  • 本身的实现机制上的限制(采用轮询方式检测就绪事件，时间复杂度: O(n)，每次还要将臃肿的 fd_set 在用户空间和内核空间拷贝来拷贝去)，并发连接越大，性能越差。
  • poll 相比 select 没有很大差异，只是取消了最大文件描述符个数的限制。
  • select/poll 都是 LT 模式。

epoll

  • 采用回调方式检测就绪事件，时间复杂度: O(1)，每次 epoll_wait 调用只返回已就绪的文件描述符。
  • epoll 支持 LT 和 ET 模式。

7 稍微深入了解一点 Epoll

LT vs ET

概念：

  • LT：level-triggered 水平触发
  • ET：edge-triggered 边沿触发

可读：

  • buffer 不为空的时候 fd 的 events 中对应的可读状态就被置为1，否则为0。

可写：

  • buffer 中有空间可写的时候 fd 的 events 中对应的可写状态就被置为1，否则为0。

图解：

image.png

epoll 三个方法简介

1）主要代码：linux-2.6.11.12/fs/eventpoll.c

2）int epoll_create(int size)

创建 rb-tree(红黑树)和 ready-list (就绪链表)：

  • 红黑树O(logN)，平衡效率和内存占用，在容量需求不能确定并可能量很大的情况下红黑树是最佳选择。
  • size参数已经没什么意义，早期epoll实现是hash表，所以需要size参数。

3）int epoll_ctl(int epfd，int op，int fd，struct epoll_event *event)

  • 把epitem放入rb-tree并向内核中断处理程序注册ep_poll_callback，callback触发时把该epitem放进ready-list。

4）int epoll_wait(int epfd，struct epoll_event * events，int maxevents，int timeout)

  • ready-list —> events[]。

epoll 的数据结构

image.png

epoll_wait 工作流程概述

对照代码：linux-2.6.11.12/fs/eventpoll.c：

1）epoll_wait 调用 ep_poll

  • 当 rdlist(ready-list) 为空(无就绪fd)时挂起当前线程,直到 rdlist 不为空时线程才被唤醒。

2）文件描述符 fd 的 events 状态改变

  • buffer由不可读变为可读或由不可写变为可写，导致相应fd上的回调函数ep_poll_callback被触发。

3）ep_poll_callback 被触发

  • 将相应fd对应epitem加入rdlist，导致rdlist不空，线程被唤醒，epoll_wait得以继续执行。

4）执行 ep_events_transfer 函数

  • 将rdlist中的epitem拷贝到txlist中，并将rdlist清空。
  • 如果是epoll LT，并且fd.events状态没有改变(比如buffer中数据没读完并不会改变状态)，会再重新将epitem放回rdlist。

5）执行 ep_send_events 函数

  • 扫描txlist中的每个epitem，调用其关联fd对应的poll方法取得较新的events。
  • 将取得的events和相应的fd发送到用户空间。

8 Netty 的最佳实践

1）业务线程池必要性

  • 业务逻辑尤其是阻塞时间较长的逻辑，不要占用netty的IO线程，dispatch到业务线程池中去。

2）WriteBufferWaterMark

  • 注意默认的高低水位线设置(32K~64K)，根据场景适当调整(可以思考一下如何利用它)。

3）重写 MessageSizeEstimator 来反应真实的高低水位线

  • 默认实现不能计算对象size，由于write时还没路过任何一个outboundHandler就已经开始计算message size，此时对象还没有被encode成Bytebuf，所以size计算肯定是不准确的(偏低)。

4）注意EventLoop#ioRatio的设置(默认50)

  • 这是EventLoop执行IO任务和非IO任务的一个时间比例上的控制。

5）空闲链路检测用谁调度?

  • Netty4.x默认使用IO线程调度，使用eventLoop的delayQueue，一个二叉堆实现的优先级队列，复杂度为O(log N)，每个worker处理自己的链路监测，有助于减少上下文切换，但是网络IO操作与idle会相互影响。
  • 如果总的连接数小，比如几万以内，上面的实现并没什么问题，连接数大建议用HashedWheelTimer实现一个IdleStateHandler，HashedWheelTimer复杂度为 O(1)，同时可以让网络IO操作和idle互不影响，但有上下文切换开销。

6）使用ctx.writeAndFlush还是channel.writeAndFlush?

  • ctx.write直接走到下一个outbound handler，注意别让它违背你的初衷绕过了空闲链路检测。
  • channel.write从末尾开始倒着向前挨个路过pipeline中的所有outbound handlers。

7）使用Bytebuf.forEachByte() 来代替循环 ByteBuf.readByte()的遍历操作，避免rangeCheck()

8）使用CompositeByteBuf来避免不必要的内存拷贝

  • 缺点是索引计算时间复杂度高，请根据自己场景衡量。

9）如果要读一个int，用Bytebuf.readInt()，不要Bytebuf.readBytes(buf，0，4)

  • 这能避免一次memory copy (long，short等同理)。

10）配置UnpooledUnsafeNoCleanerDirectByteBuf来代替jdk的DirectByteBuf，让netty框架基于引用计数来释放堆外内存

io.netty.maxDirectMemory：

  • < 0: 不使用cleaner，netty方面直接继承jdk设置的最大direct memory size，(jdk的direct memory size是独立的，这将导致总的direct memory size将是jdk配置的2倍)。
  • == 0: 使用cleaner，netty方面不设置最大direct memory size。
0：不使用cleaner，并且这个参数将直接限制netty的最大direct memory size，(jdk的direct memory size是独立的，不受此参数限制)。

11）最佳连接数

  • 一条连接有瓶颈，无法有效利用cpu，连接太多也白扯，最佳实践是根据自己场景测试。

12）使用PooledBytebuf时要善于利用 -Dio.netty.leakDetection.level 参数

  • 四种级别：DISABLED(禁用)，SIMPLE(简单)，ADVANCED(高级)，PARANOID(偏执)。
  • SIMPLE，ADVANCED采样率相同，不到1%(按位与操作 mask ==128 - 1)。
  • 默认是SIMPLE级别，开销不大。
  • 出现泄漏时日志会出现“LEAK: ”字样，请时不时grep下日志，一旦出现“LEAK: ”立刻改为ADVANCED级别再跑，可以报告泄漏对象在哪被访问的。
  • PARANOID：测试的时候建议使用这个级别，100%采样。

13）Channel.attr()，将自己的对象attach到channel上

  • 拉链法实现的线程安全的hash表，也是分段锁(只锁链表头)，只有hash冲突的情况下才有锁竞争(类似ConcurrentHashMapV8版本)。
  • 默认hash表只有4个桶，使用不要太任性。

9 从 Netty 源码中学到的代码技巧

1）海量对象场景中 AtomicIntegerFieldUpdater --> AtomicInteger

  • Java中对象头12 bytes(开启压缩指针的情况下)，又因为Java对象按照8字节对齐，所以对象最小16 bytes，AtomicInteger大小为16 bytes，AtomicLong大小为 24 bytes。
  • AtomicIntegerFieldUpdater作为static field去操作volatile int。

2）FastThreadLocal，相比jdk的实现更快

  • 线性探测的Hash表 —> index原子自增的裸数组存储。

3）IntObjectHashMap / LongObjectHashMap …

  • Integer—> int
  • Node[] —> 裸数组

4）RecyclableArrayList

  • 基于前面说的Recycler，频繁new ArrayList的场景可考虑。

5）JCTools

  • 一些jdk没有的 SPSC/MPSC/SPMC/MPMC 无锁并发队以及NonblockingHashMap(可以对比ConcurrentHashMapV6/V8)

招聘

我们是蚂蚁智能监控技术中台的存储团队，我们正在使用 Rust/Go/Java 构建高性能、低成本具备实时分析能力的新一代时序数据库，欢迎转岗或者推荐，联系人：冯家纯 jiachun.fjc@antgroup.com

参考资料

[1]Netty

[2]JDK-source

  • /jdk/src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java
  • /jdk/src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java
  • /jdk/src/solaris/native/sun/nio/ch/EPollArrayWrapper.c

[3]Linux-source

[4]RPS/RFS

[5]I/O Multiplexing

[6]jemalloc

[7]SO_REUSEPORT

[8]TCP_FASTOPEN

[9]最佳实践主要参考来源

[10]https://github.com/eishay/jvm-serializers/wiki

[11]https://github.com/OpenHFT/Java-Thread-Affinity

Alibaba Cloud Linux技术图谱

业界权威专家出品，共 18 个知识点，79 课时 ，基于 Alibaba Cloud Linux 结合阿里巴巴工程师的一线实战经验，邀请行业在职运维工程师授课，课程内容涵盖 Linux 基础知识、常用业务服务维护、自动化运维、自动化运维监控、KVM 虚拟化等相关知识。

点击这里，开始学习吧~

文章标签：
云数据库 ClickHouse
Java
监控
运维
Linux
Unix
负载均衡
API
中间件
调度
存储
关键词：
分布式框架
分布式服务
高性能分布式
Netty高性能
Netty框架
开发者小助手_LS
目录
相关文章
我是快乐的嘟嘟
|
1月前
|
Java 数据库
在Java中使用Seata框架实现分布式事务的详细步骤
通过以上步骤，利用 Seata 框架可以实现较为简单的分布式事务处理。在实际应用中，还需要根据具体业务需求进行更详细的配置和处理。同时，要注意处理各种异常情况，以确保分布式事务的正确执行。
我是快乐的嘟嘟
82 7
我是快乐的嘟嘟
|
1月前
|
消息中间件 Java Kafka
在Java中实现分布式事务的常用框架和方法
总之，选择合适的分布式事务框架和方法需要综合考虑业务需求、性能、复杂度等因素。不同的框架和方法都有其特点和适用场景，需要根据具体情况进行评估和选择。同时，随着技术的不断发展，分布式事务的解决方案也在不断更新和完善，以更好地满足业务的需求。你还可以进一步深入研究和了解这些框架和方法，以便在实际应用中更好地实现分布式事务管理。
我是快乐的嘟嘟
64 7
喜欢猪猪
|
2月前
|
存储 缓存 算法
分布式锁服务深度解析：以Apache Flink的Checkpointing机制为例
【10月更文挑战第7天】在分布式系统中，多个进程或节点可能需要同时访问和操作共享资源。为了确保数据的一致性和系统的稳定性，我们需要一种机制来协调这些进程或节点的访问，避免并发冲突和竞态条件。分布式锁服务正是为此而生的一种解决方案。它通过在网络环境中实现锁机制，确保同一时间只有一个进程或节点能够访问和操作共享资源。
喜欢猪猪
92 3
卷福同学
|
8天前
|
消息中间件 存储 安全
分布式系统架构3：服务容错
分布式系统因其复杂性，故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定？本文详细介绍了分布式架构中7种核心的服务容错策略，包括故障转移、快速失败、安全失败等，以及它们在实际业务场景中的应用。无论是支付场景的快速失败，还是日志采集的安全失败，每种策略都有自己的适用领域和优缺点。此外，文章还为技术面试提供了解题思路，助你在关键时刻脱颖而出。掌握这些策略，不仅能提升系统健壮性，还能让你的技术栈更上一层楼！快来深入学习，走向架构师之路吧！
卷福同学
43 11
郑小健
|
7天前
|
分布式计算 大数据 数据处理
技术评测：MaxCompute MaxFrame——阿里云自研分布式计算框架的Python编程接口
随着大数据和人工智能技术的发展，数据处理的需求日益增长。阿里云推出的MaxCompute MaxFrame（简称“MaxFrame”）是一个专为Python开发者设计的分布式计算框架，它不仅支持Python编程接口，还能直接利用MaxCompute的云原生大数据计算资源和服务。本文将通过一系列最佳实践测评，探讨MaxFrame在分布式Pandas处理以及大语言模型数据处理场景中的表现，并分析其在实际工作中的应用潜力。
郑小健
34 2
dufadayang
|
1月前
|
存储 Java 关系型数据库
在Spring Boot中整合Seata框架实现分布式事务
可以在 Spring Boot 中成功整合 Seata 框架，实现分布式事务的管理和处理。在实际应用中，还需要根据具体的业务需求和技术架构进行进一步的优化和调整。同时，要注意处理各种可能出现的问题，以保障分布式事务的顺利执行。
dufadayang
51 6
dufadayang
|
1月前
|
数据库
如何在Seata框架中配置分布式事务的隔离级别？
总的来说，配置分布式事务的隔离级别是实现分布式事务管理的重要环节之一，需要认真对待和仔细调整，以满足业务的需求和性能要求。你还可以进一步深入研究和实践 Seata 框架的配置和使用，以更好地应对各种分布式事务场景的挑战。
dufadayang
29 6
dufadayang
|
28天前
|
消息中间件 运维 数据库
Seata框架和其他分布式事务框架有什么区别
Seata框架和其他分布式事务框架有什么区别
dufadayang
25 1
龙大吉
|
1月前
|
缓存 NoSQL PHP
Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点，在提升应用响应速度和处理能力方面表现突出
本文深入探讨了Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点，在提升应用响应速度和处理能力方面表现突出。文章还介绍了Redis在页面缓存、数据缓存和会话缓存等应用场景中的使用，并强调了缓存数据一致性、过期时间设置、容量控制和安全问题的重要性。
龙大吉
43 5
喜欢猪猪
|
1月前
|
消息中间件 编解码 网络协议
Netty从入门到精通：高性能网络编程的进阶之路
【11月更文挑战第17天】Netty是一个基于Java NIO（Non-blocking I/O）的高性能、异步事件驱动的网络应用框架。使用Netty，开发者可以快速、高效地开发可扩展的网络服务器和客户端程序。本文将带您从Netty的背景、业务场景、功能点、解决问题的关键、底层原理实现，到编写一个详细的Java示例，全面了解Netty，帮助您从入门到精通。
喜欢猪猪
148 0

阿里技术

热门文章

最新文章

  • 1
    Nettyの网络聊天室&扩展序列化算法
  • 2
    鸿蒙HarmonyOS应用开发 |鸿蒙技术分享HarmonyOS Next 深度解析：分布式能力与跨设备协作实战
  • 3
    使用Python实现深度学习模型的分布式训练
  • 4
    大厂都在用的分布式事务方案，Seata+RocketMQ带你打破10万QPS瓶颈
  • 5
    鸿蒙HarmonyOS应用开发 | 探索 HarmonyOS Next-从开发到实战掌握 HarmonyOS Next 的分布式能力
  • 6
    PolarDB 分布式版 V2.0，安全可靠的集中分布式一体化数据库管理软件
  • 7
    使用lock4j-redis-template-spring-boot-starter实现redis分布式锁
  • 8
    分布式读写锁的奥义：上古世代 ZooKeeper 的进击
  • 9
    分布式机器学习系统：设计原理、优化策略与实践经验
  • 10
    基于Redis海量数据场景分布式ID架构实践
  • 1
    服务器数据恢复—Lustre分布式文件系统服务器数据恢复案例
    13
  • 2
    【SpringCloud Alibaba系列】一文全面解析Zookeeper安装、常用命令、JavaAPI操作、Watch事件监听、分布式锁、集群搭建、核心理论
    25
  • 3
    分布式Python计算服务MaxFrame使用心得
    25
  • 4
    从零到一：分布式缓存技术初探
    16
  • 5
    分布式系统架构5：限流设计模式
    39
  • 6
    鸿蒙HarmonyOS应用开发 | 探索 HarmonyOS Next-从开发到实战掌握 HarmonyOS Next 的分布式能力
    121
  • 7
    鸿蒙HarmonyOS应用开发 |鸿蒙技术分享HarmonyOS Next 深度解析：分布式能力与跨设备协作实战
    150
  • 8
    云产品评测：MaxFrame — 分布式Python计算服务的最佳实践与体验
    30
  • 9
    一致性哈希：解决分布式难题的神奇密钥
    35
  • 10
    分布式系统架构4：容错设计模式
    31

    • 相关课程

    更多
  • 开源PolarDB分布式版部署实操
  • Spring Boot+Vue.js+FastDFS实现分布式图片服务器
  • 基于Zookeeper、Dubbo构建互联网分布式基础架构
  • 分布式文件存储系统技术及实现
  • 分布式协调系统 Zookeeper 快速入门
  • 微服务实战-RocketMQ Binder

    • 相关电子书

    更多
  • 高并发分布式缓存Redis6.0
  • 基于社区的分布式 风险感知模型
  • 如何利用Redisson分布式化传统Web项目

    • 相关实验场景

    更多
  • 体验PolarDB-X透明分布式
  • 高性能特性体验：ePQ 的详解与实战
  • 通过部署流行Web框架掌握Serverless技术
    • 下一篇
    DataWorks售前咨询