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

解道是使用基于Jdonframework的jivejdon开发的。其中使用到的性能加速技术有：

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

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

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

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

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

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

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

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

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

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

这种即用即加载和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与外部特征有关的数据。这和从外部看球与走到球内部的道理是一样的。

确实很快，体验很棒。 感觉Jdon的风格一点都不浮躁。
[该贴被alexwoo于2012-09-20 21:54修改过]

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

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

请问 jdon只用一台服务器么？什么配置啊？

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

CRQS 架构能详细举例吗？

如果这么严格追求安全性，可以参考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修改过]

能针对中国铁路网订票使用LMAX架构，在其功能上展开一下吗？
如何针对查询、订票、支付等进行设计、部署？
订单提交：余票检查与订单创建是在同一个交易中的，查询（余票检查）与更新（订单创建）能异步吗？提高了系统可用性的同时怎么让数据一致性不下降？

订单创建实际是资源号和用户ID关联，资源号是票号，代表座位等等。

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

disruptor怎么看怎么都像计算机“中断”，一个是处理业务，一个是处理CPU与外设的，举个例子：
打印中断：
1、CPU主程序中发出打印机启动指令，不等待打印机初试化，继续执行主程序，
2、打印机就绪，主动向CPU发出中断指令
3、CPU中断当前程序进行打印处理
4、打印完成，继续执行主程序
订票：
1、系统接受到订票请求，向服务器发出余票检查请求，继续处理其他订票请求；
2、当前有空余的座位，主动向系统发出中断请求，
3、CPU中断当前订票请求，进行处理创建订单。
4、订单创建成功，继续处理其他订票请求。

一个系统应该设计成若干disruptor组成，每个disruptor完成一个交易过程？
(类似分布式计算)
还是一个系统由若干disruptor组成，每一个disruptor处理所有的业务，业务请求分散到每一个disruptor之中？（类似集群计算）

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

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

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

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