manzhizhen
- 浏览: 289740 次
- 性别:
- 来自: 杭州
-
最新评论
-
yingwuluohan：
楼主，最近有关JVM的一个问题实在是抓狂，深究无果，还望楼主能 ...
Java中如何限制方法访问的并发数 -
manzhizhen：
xiangqianzou_liu 写道"所以显然Re ...
Dubbo源代码实现二：服务调用的动态代理和负载均衡 -
xiangqianzou_liu：
"所以显然ReferenceConfig实现了Fac ...
Dubbo源代码实现二：服务调用的动态代理和负载均衡 -
otboy123：
otboy123 写道请问，您说的和 feign 的 注解里面 ...
Hystrix浅入浅出：（一）背景与功能初探 -
otboy123：
请问，您说的和 feign 的 注解里面的 fallback机 ...
Hystrix浅入浅出：（一）背景与功能初探
文章列表
虽然我们系统的用户体验和数据一致性不应该完全靠优雅停机来保证，但作为一流的RPC框架，优雅停机的功能必不可少，Dubbo用户手册有对优雅停机做一个简单的叙述：
Dubbo是通过JDK的 ShutdownHook 来完成优雅停机的,所以如果用户使用 kill -9 PID 等强制关闭指令,是不会执行优雅停机的,只有通过 kill PID 时,才会执行。
服务提供方：停止时,先标记为不接收新请求,新请求过来时直接报错,让客户端重试其它机器。然后,检测线程池中的线程是否正在运行,如果有,等待所有线程执行完成,除非超时,则强制关闭。
服务消费方：停止时,不再发起新的调用请求,所有新的调用在 ...
在上回《Dubbo源代码实现六》中我们已经了解到，对于Dubbo集群中的Provider角色，有IO线程池（默认无界）和业务处理线程池（默认200）两个线程池，所以当业务的并发比较高，或者某些业务处理变慢，业务线程池就很容易被“打满”，抛出“RejectedExecutionException: Thread pool is EXHAUSTED! ”异常。当然，前提是我们每给Provider的线程池配置等待Queue。
既然Provider端已经抛出异常，表明自己已经受不了了，但线上我们却发现，
我们知道，在Dubbo中可以给Provider配置线程池大小来控制系统提供服务的最大并行度，默认是200个，如果我们想配置成500，可以如下配置：
<dubbo:provider token="true" threads="500"/>
当我们想限制某个dubbo服务使用的最大线程数量时，dubbo提供了executes这一属性来提供这
对于Dubbo的服务提供者，主要有两种线程池，一种是IO处理线程池，另一种是服务调用线程池。而作为IO处理线程池，由于Dubbo基于Mina、Grizzly和Netty框架做IO组件，IO线程池都是基于这些框架来配置，比如Netty中的boss和worker线程池，Dubbo选择的是“无边界”的CachedThreadPool，这意味着对所有服务请求先做到“来者不拒”，但它进一步限制了IO处理的线程数，默认是核数+1，本文拿Netty
SPI的全称是Service Provider Interface，即服务提供商接口。直白的说，它主要用来实现一个可扩展的Java应用。有人会觉得这就是建立在面向接口编程下的一种为了使组件可扩展或动态变更实现的规范，常见的类SPI的设计有JDBC、JNDI、JAXP等，很多开源框架的内部实现也采用了SPI，。例如JDBC的架构是由一套API组成，用于给Java应用提供访问不同数据库的能力，而数据库提供商的驱动软件各不相同，JDBC通过提供一套通用行为的API接口，底层可以由提供商自由实现，虽然JDBC的设计没有指明是SPI，但也和SPI的设计类似。这里有兴趣的读者可以参看2002 ...
<!--StartFragment--> 我们知道，对于服务治理框架来说，服务通信（RPC）和服务管理两部分必不可少，而服务管理又分为服务注册、服务发现和服务人工介入，我们来看看Dubbo框架的结构图（来源网络）：<!--EndFragment-->
图中可以看出，服务提供者Provider往服务注册中心Registry注册服务，而的消费者Consumer从服务注册中心订阅它需要的服务，而不是全部服务，当有新的Provider出现，或者现有Provider宕机，注册中心Registry都应该能尽早发现，并将新的Provider列表推送给对应的 ...
刚开始使用Dubbo的人，可能对Dubbo的第一印象就是它是一个RPC框架，当然，所有的分布式框架都少不了相互通信的过程，何况Dubbo的任务就是帮助分布式业务系统完成服务的通讯、负载、注册、发现和监控等功能。不得不承认，RPC是Dubbo提供服务的核心流程，为了兼容多种使用场景，Dubbo显然需要提供多种RPC方式（协议）.
开发一个简单的RPC框架，重点需要考虑的是两点，即编解码方式和底层通讯协议的选型，编解码方式指的是需要传输的数据在调用方将以什么组织形式拆解成字节流并在服务提供方以什么形式解析出来。编解码方式的设计需要考虑到后期的版本升级，所以很多 ...
第一次真正接触Java消息服务是在2013年底，当时是给中国移动做统一支付平台，当时用的就是著名的Apache ActiveMQ，当时觉得很有趣，一个服务队列竟然可以玩出这么多花样来。当时为了尽快的入门，还把《Java Message Service》给看了一遍，这对于初学者的我收获颇多。我说知道的完全实现JMS规范的MOM有ActiveMQ/Apollo和HornetQ，都是采用Java实现。JMS中说明了Java消息服务的两种消息传送模型，即P2P（点对点）和
疑惑一：为什么在Spring中我们能像注入普通本地服务JavaBean一样注入远程的Dubbo服务Bean？
我们知道，Dubbo将服务调用封装成普通的Spring的Bean，于是我们可以像使用本地的Spring Bean一样，来调用远端的Dubbo服务，并有LoadBalance和Failover的功能。现在，我们从源码的角度来看看，
我们知道，java.util.concurrent.locks包下的Lock和Condition接口的语义是用来替代JDK1.5之前使用synchronize和Object.wait、Object.notify、Object.notifyAll组合，Effective Java一书中说过，JDK1.5及其以后，你几乎没有任何理由去选择使用synchronize和Object.wait、Object.notify、
信号量Semaphore是java.util.concurrent包下一个常用的同步工具类，它维护了一个许可集，可以理解成资源数，可以通过acquire操作来获取一个资源，并通过release来释放一个资源，但需要注意的是，release来释放资源前不一定 ...
毫不为过的说，AbstractQueuedSynchronizer(以下简称AQS)是java.util.concurrent包下同步器类的灵魂组件，很多同步组件都是基于它实现的，比如CountDownLatch、CyclicBarrier、ReentrantLock、ReentrantReadWriteLock和ConcurrentHashMap等。
我们不要一头栽进AQS的代码里直接看，因为是DougLea大神写的，直接看会有点晕。我们来回顾一下我们用过的同步工具类，其中通用的核心操作有如下几种方式：
虽然我们把FlumeEventQueue想象成Event指针的内存队列，但FlumeEventQueue中的内部实现是很绕的，不跑跑Flume的单元测试，很容易看晕。本文的目的就是通过简化模型来剖析FlumeEventQueue中的四种操作：addTail、removeHead、addHead和remove。
上一篇博文地址：http://manzhizhen.iteye.com/admin/categories/357759
FlumeEventQueue中（准确的说应该是EventQueueBackingStore中）有queueSize和q ...
有了前两篇博文的基础，相信大家对Flume Agent的内部结构已经有了个初步的了解，现在我们来详细介绍最常用的文件通道——File Channel，本篇博客主要介绍Eevnt是如何完成写到File Channel这一操作的。
上一篇： http://manzhizhen.iteye.com/blog/2298159
Channel是联系Source和Sink的桥梁，内存Memory Channel性能虽高，但对于日志数据处理这块，实时并不是第一重要的，几乎所有以日志作为数据源的数据分析都只能说是近乎实时的。对于大多数数据分析来说，日志丢失是 ...
上一篇文章简单介绍了下Flume的背景，接下来本文说说Flume NG的内部设计。注意：本文针对的是Flume1.6.0版本。
上一篇：http://manzhizhen.iteye.com/blog/2298150
我们先来看看为什么需要Flume，在大数据分析领域，最 ...