海浪儿
- 浏览: 271857 次
- 性别:
- 来自: 杭州
-
最新评论
-
天然呆的爱死你了呢：
herman_liu76 写道3) Handler执 ...
NIO+reactor模式的网路服务器设计方案 -
天然呆的爱死你了呢：
很棒，顶！
NIO+reactor模式的网路服务器设计方案 -
萨琳娜啊：
Java读源码之Netty深入剖析网盘地址：https://p ...
netty4源码分析-connect -
kyorisvc2012：
EventLoopGroup和EventLoop的继承关系感觉 ...
netty4服务端启动源码分析-线程的创建 -
herman_liu76：
3) Handler执行 task，读取客户端的请求 ...
NIO+reactor模式的网路服务器设计方案
文章列表
本文为原创，转载请注明出处
开放平台体系结构及网关分析
开放平台以API的方式将公司的核心基础服务（譬如支付、交易等）开放给ISV（Independent Software Vendors，独立软件开发商），而这些功能由公司的各业务平台（ ...
本文为原创，转载请注明出处
JAVA/PHP/C#版RSA验签
本文是上一篇文章的兄弟篇，上篇文章介绍了客户端的sdk中如何基于JAVA/PHP/C#使用RSA私钥签名，然后服务端基于JAVA使用RSA公钥验签，客户端签名/服务端验签的模式只能帮助服务端检查客户端来的请求数据是否被篡改，同样的，客户端也需要对服务端的返回结果检查是否被篡改，因此就引出了本片文章。
Java版的验签和加签均已在上一篇文章中分析过，客户端和服务端的逻辑是一样的，此处不再赘述。下面重点分析如何基于RSA的PEM文件，使用php和c#进行验签。
Netty4源码分析-NioEventLoop实现的线程运行逻辑
在netty服务端启动源码分析-线程创建一文中已分析SingleThreadEventExecutor所持有的线程的运行逻辑由NioEventLoop实现，那么本文就着手分析NioEventLoop实现的线程运行逻辑：
// NioEventLoop
protected void run() {
for (;;) {
oldWakenUp = wakenUp.getAndSet(false);
try {
...
本文为原创，转载请注明出处
netty4服务端启动源码分析-线程的创建
本文分析Netty中boss和worker的线程的创建过程：
以下代码是服务端的启动代码，线程的创建就发生在其中。
EventLoopGroup bossGroup = new NioEventLoopGroup();
NioEventLoopGroup的类关系图如下：
构造方法执行过程如下：
// NioEventLoopGroup
public NioEventLoopGroup() {
this(0);
}
public NioEventLoop ...
本文为原创，转载请注明出处
netty4源码分析-bind
在前一篇文章中分析了监听套接字ServerSocketChannel的创建过程，本文接着分析绑定IP和端口的过程。
回到之前未分析完的doBind逻辑，前一篇文章已分析到dobind方法中initAndRegister方法，该方法最终触发了对regPromise 的listener的回调，Listener将bind任务加到boss线程的任务队列中
//AbstractBootstrap
private ChannelFuture AbstractBootstrap doBind(final SocketAddress ...
本文为原创，转载请注明出处
netty4源码分析-socket
服务端启动的第一步必须先创建一个监听套接字ServerSocketChannel，该过程是由ChannelFuture f = b.bind(port)中的bind触发。下面详细分析其过程：
Bind源码如下，代码位于ServerBootstrap的父类AbstractBootstrap
//AbstractBootstrap
public ChannelFuture bind(int inetPort) {
return bind(new InetSocketAddres ...
netty 4.x源码分析
服务端需要经过socket、bind、accept、read、write等步骤，客户端需要经过socket、connect、read、write等步骤，后续此系列文章会对每一个步骤如何发生进行分析。
netty4源码分析-线程的创建
netty4源码分析-socket
netty4源码分析-bind
Netty4源码分析-NioEventLoop实现的线程运行逻辑
netty4源码分析-connect
netty4源码分析-accept
netty4源码分析-write
netty4源码分析-flush
...
本文为原创，转载请注明出处
分库分表对老业务功能带来的冲击
当业务量发展到一定的程度时，不可避免的需要对数据进行分库分表。以用户的签约数据为例，当用户量很少时，单库单表是可以满足的，但当用户量达到某个级别，譬如亿级，那么单库就会成为瓶颈，需要根据某种维度（譬如userId）来进行分库分表。
分库分表如何实现本文就不阐述了，可以参考一下淘宝的tddl。本文主要阐述分库分表过程中对老业务逻辑带来的冲击以及如何改造，因为有些原来单库单表中很容易实现的功能，一经分库分表后，就变的很棘手，譬如：
a）根据主键
在一个产品研发过程中，一般在发布前都有线下测试阶段，那么是不是线下测试验证通过后，就可以直接将产品的新代码发布上线，覆盖原来的版本呢？这样做其实有很大的风险，因为线下测试的运行环境和线上环境不是完全 ...
在做开放平台的文档中心过程中，由于api文档不是经常变化的，所以如果每次页面渲染的时候，都去查询DB获取数据，这种性能浪费就太大了，而且文档中心是不需要登录就可以访问的，这样会给DB带来很大的压力。
对于这种情况，可以采用静态文件方案，基本思路如下：
小二在后台发布api时，api管控后台基于velocity生成静态文档，并将该文档存储至共享文件目录，存储的完整路径根据预定的规则来确定。
用户访问api文档时，文档中心前台根据api的名称确定文档在共享文件目录存储的完整路径，然后解析文档，最终展现给用户以下代码示例如何基于velocity生成静态文档
publ ...
对于某类数据，如果读的频率远远大于写的频率，数据不会经常被修改，则最适合采用本地缓存。但使用缓存，不可避免的就需要对缓存进行更新。
最近在做一个项目的时候，发现多个老系统里采用了一种不安全的更新方案，该方案的主要思路如下：
/** 本地缓存 */
private List<InterfaceConfig> configs = null;
/** 本地缓存的上次更新时间 */
private long lastUpdateTime = 0;
public List<InterfaceConf ...
在开放平台领域，需要给isv提供sdk，签名是Sdk中需要提供的功能之一。由于isv使用的开发语言不是单一的，因此sdk需要提供多种语言的版本。譬如java、php、c#。另外，在电子商务尤其是支付领域，对安全性的要求比较高，所以会采用非对称密钥RSA
本文主要介绍如何基于java、php、c#在客户端使用rsa签名，然后在服务端使用Java验签。
基于openssl生成RSA公私钥对
a）从网上下载openssl工具:http://www.slproweb.com/products/Win32OpenSSL.html
b）生成私钥
...
最近由于开放平台项目的需要，在写php版的sdk，过程中碰到一些问题，做个记号，以免后面忘记
Php发送请求参数丢失：
curl_setopt($ch, CURLOPT_POSTFIELDS, substr($postBodyString, 0, -1));
$reponse
NIO+reactor 模式的网路服务器设计方案
1、前言
在前一篇文章中，介绍了基于 BlockingIO +thread-per-connection 的方案，由于该方案为每一个连接分配一个线程，而线程里的大部分操作都是阻塞式的，所以在高并发的情况下，会导致产生大量的线程，线程间的上下文切换会浪费大量的 CPU 时间，而且每个线程是需要占用堆栈空间的，所以服务器能分配的线程数量也是有限的，当客户端的并发访问量达到一定的数量级后，服务器的资源就会耗尽，可伸缩性差。
根据上面的分析，要提高网络服务器的可伸缩性，就必须解决两个问 ...
BlockingIO +thread-per-connection的网络服务器设计方案
1、 前言
在 java1.4引入 NIO之前，网络服务器的典型实现方案是采用阻塞 IO+多线程模型，后来出现了非阻塞 IO（ NIO），常用的实现方案则变成 NIO+Reactor模式，还有 NIO+proactor模式。本文主要是介绍阻塞 IO+多线程模型，虽然该方案有很多缺点，但此处还对此进行介绍的原因是为后面进一步介绍基于 NIO的方案做准备，毕竟研究一种新的方案时，只有知道它出现之前的老的方案的缺点后，才能对新的方案理解的更深。
...