为什么解道访问速度这么快

12-09-19 tianhandigeng
10年的时候就开始接触到j道了,我发现页面打开速度是相当的快,基本上1、2秒钟就搞定了,用起来有“很滑”的感觉,不知道J道的高明之处在哪,为什么打开页面速度如此的快?

[该贴被admin于2012-09-20 11:10修改过]

36
banq
2012-09-19 07:13
解道是使用基于Jdonframework的jivejdon开发的。其中使用到的性能加速技术有:

1.Disruptor并发加载技术,浏览一个帖子时,有很多数据表需要加载,jivejdon只加载主要值对象MessageVO相关的数据表,其他数据表只是在需要访问时使用。

2.基于内存的DDD模型技术,帖子实体常驻内存,帖子更新基于内存更新,异步更新数据库。

3.采取客户端缓存技术,对于帖子没有更新的,发送304给浏览器,节省带宽。

4.杜绝Cookie,只有登录用户才有Cookie,只读用户没有任何Cookie,并且根据帖子时间有一定的expire时间。

JiveJdon基本采取了目前能够采取的各种性能加速技术,之所以能够拓展到如此极致,关键是JiveJdon的读写分离的清晰CQRS架构。

[该贴被banq于2012-09-20 08:53修改过]

banq
2012-09-19 07:28
总体来说,是动态页面静态化,我以前说过:静态页面其实也是动态页面,静态页面是通过Apache或Nginx这些类似Java的C程序加载推送到客户端的,关键在于Http协议的设置,现在通过Java将动态页面模拟成静态页面,去除页面中和客户端有关的信息,不要每次加载页面内容不一样,去除Cookie等等综合方式。

还有反爬虫机制,对于各种不正常扫描使用fail2ban及时封杀。

使用的主机是阿里云最便宜的经济A型。

[该贴被banq于2012-09-20 08:53修改过]

banq
2012-09-20 12:26
2012-09-19 07:13 "@banq"的内容
Disruptor并发加载技术,浏览一个帖子时,有很多数据表需要加载,jivejdon只加载主要值对象MessageVO相关的数据表,其他数据表只是在需要访问时使用 ...

这种即用即加载和Hibernate的延迟加载或AJAX的异步加载是有区别的,AJAX的异步加载会发出很多Http请求;而Hibernate等延迟加载是无法跨请求的,只能在一个请求响应发往客户端结束前全部完成。

而基于Jdonframework+disruptor的即用即加载是跨请求的,也就是说,只有当第一次输出JSP页面时,需要访问模型对象的getXXX方法时,才会从数据库中加载。

当然,所有这些都必须以DDD模型对象为中心设计,这里也涉及到聚合根的设计。可以设计两种聚合根,一个负责对外,一个负责对内。

所谓对外,打个比喻,当我们看到一个球时,我们这时处于球的外部,看到的是球的表面特征,比如球面光滑等的;而当我们走到球内部,看到球里面有很多房子,这是对内。

我们人观察任何事物都有这样内外分别,那么在访问模型对象时,也有内外之分,这时聚合根就要负责其内外分别的职责。

比如DDD书籍中Car和发动机两个都是聚合根,发动机是提供Car内部动力,而Car则是一个集合概念,负责对外,我们首先看到的是CAR,走到Car内部,我们才感受到发动机。

但是Car和发动机的区别是:发动机你可以看到一个具体机器,而Car则没有具体形态,它内部是由发动机 车轮 车厢等组成,只有你走出Car内部,才看到Car的形态,这时Car其实是一种外表边界而已。

所以,一般重建聚合根时,我们可以倾向于先构建一个框架聚合根Car,然后由Car负责加载重建其内部一个个元素组件。

jivejdon论坛聚合根也是由Thread这个组合体和RootMessage这两个聚合根,因此加载一个帖子时,首先加载一个Thread,其他部分加载看情况而定,如果是要看帖子内部内容,届时显示时会加载与内容显示相关的部件;而如果只是想看看很多Thread列表,从外部看Thread,那届时就会加载Thread与外部特征有关的数据。这和从外部看球与走到球内部的道理是一样的。

alexwoo
2012-09-20 21:52
确实很快,体验很棒。 感觉Jdon的风格一点都不浮躁。

[该贴被alexwoo于2012-09-20 21:54修改过]

banq
2012-09-21 06:51
多谢,技术发展有自己的规律,有些技术不是你加班短时间内多花时间就能掌握,吃饭也有吃饱的时候。如果为了显式名气或单纯追求做大做强人气旺,就会忽视聆听技术自身的旋律。

chanball
2012-09-21 13:09
2012-09-19 07:13 "@banq"的内容
JiveJdon基本采取了目前能关键是JiveJdon的读写分离的清晰CQRS架构。 ...

这一块很感兴趣,可以详细一点吗

mistbow
2012-09-21 16:36
请问 jdon只用一台服务器么?什么配置啊?

liweinan0423
2012-09-21 17:56
2012-09-19 07:13 "@banq"的内容
2.基于内存的DDD模型技术,帖子实体常驻内存,帖子更新基于内存更新,异步更新数据库。 ...

如果帖子在内存更新后还没来得及更新到数据库,服务器宕机,会发生数据丢失的问题,这个问题该怎么解决啊?

leiyunshi
2012-09-21 21:44
CRQS 架构能详细举例吗?

banq
2012-09-22 10:13
2012-09-21 17:56 "@liweinan0423"的内容
如果帖子在内存更新后还没来得及更新到数据库,服务器宕机,会发生数据丢失的问题 ...

如果这么严格追求安全性,可以参考LMAX架构,它们也是使用Disruptor达到一台服务器每秒处理500万个订单的吞吐量,它们采取Event Store在事件发生时立即存储,两台服务器互为failover。

顺便说一下,中国铁路网上售票12306.cn如果采取LMAX架构,国庆春节售票应该一点问题都没有,售票也是一种订单,也就是说可以每秒售出500万张票。全国人民10亿人全部来买票,需要等200秒,也就是4分钟不到就能网上排队买到票。

关于JiveJdon和CQRS架构可见专门介绍页面

本站主机是阿里云主机A型,可见其主页介绍, CPU是被搞残的一核,内存1G,如下信息:

cat /proc/cpuinfo

processor : 0

vendor_id : GenuineIntel

cpu family : 6

model : 44

model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz

stepping : 2

cpu MHz : 2400.235

cache size : 12288 KB

physical id : 0

siblings : 1

core id : 0

cpu cores : 1

多谢大家的热情关心。

[该贴被banq于2012-09-22 10:31修改过]

clonalman
2012-09-22 17:16
2012-09-22 10:13 "@banq"的内容
顺便说一下,中国铁路网上售票12306.cn如果采取LMAX架构,国庆春节售票应该一点问题都没有,售票也是一种订单,也就是说可以每秒售出500万张票。全国人民10亿人全部来买票,需要等200秒,也就是4分钟不到就能网上排队买到票。 ...

能针对中国铁路网订票使用LMAX架构,在其功能上展开一下吗?

如何针对查询、订票、支付等进行设计、部署?

订单提交:余票检查与订单创建是在同一个交易中的,查询(余票检查)与更新(订单创建)能异步吗?提高了系统可用性的同时怎么让数据一致性不下降?

banq
2012-09-22 18:05
订单创建实际是资源号和用户ID关联,资源号是票号,代表座位等等。

关联字段在内存中进行,disruptor不断读取进来的事件,首先检查关联前提条件,如果没有满足,不进行处理,而是发事件出去,让其他服务器处理,它们处理好后还是再发事件进来,这台主服务器主要进行字段关联。其他业务都不在这台机器上进行。这实际是一个批处理系统。

clonalman
2012-09-22 19:05
disruptor怎么看怎么都像计算机“中断”,一个是处理业务,一个是处理CPU与外设的,举个例子:

打印中断:

1、CPU主程序中发出打印机启动指令,不等待打印机初试化,继续执行主程序,

2、打印机就绪,主动向CPU发出中断指令

3、CPU中断当前程序进行打印处理

4、打印完成,继续执行主程序

订票:

1、系统接受到订票请求,向服务器发出余票检查请求,继续处理其他订票请求;

2、当前有空余的座位,主动向系统发出中断请求,

3、CPU中断当前订票请求,进行处理创建订单。

4、订单创建成功,继续处理其他订票请求。

一个系统应该设计成若干disruptor组成,每个disruptor完成一个交易过程?

(类似分布式计算)

还是一个系统由若干disruptor组成,每一个disruptor处理所有的业务,业务请求分散到每一个disruptor之中?(类似集群计算)

banq
2012-09-22 19:14
2012-09-22 19:05 "@clonalman"的内容
一个系统应该设计成若干disruptor组成,每个disruptor完成一个交易过程 ...

从MF的LMAX架构文章中看,属于这种,这种类似实际是一种批处理系统batch processor,看上去类似批量打印,原理类似,JVM微调也分是面向Web应用和面向批处理等几个方向,不同方向任务对内存设置不一样,Disruptor好像也有.NET版本。

LMAX架构可以说这几年西方企业应用中很瞩目很轰动的案例,2009年已经运行至今。

中国的计算机太注重科学计算和理论研究,看到微博上那么多教授学者讨论火车售票,简直成了学术秀,其实如果多关注国际应用前沿,这实际已经有成功案例。

总是新闻上看到什么超亿计算机面列全世界第一第三报道,但是全世界人口第一的中国人却还面临网络买票难,为什么不把超亿计算技术用上呢?中国人还是需要实在成本低的面列世界前茅的计算机技术吧?

猜你喜欢
2Go 1 2 下一页