刚刚看到Google黑板报的一篇短文'五一节快乐'，心想这是自己第一次五一节加班，是不是也该写点什么，不过该写些什么呢，自己心里也没个方向，那就想到哪写到哪吧！

已经连续工作7天了，自己略感到有些疲惫，今天早上醒的很早，自己做了碗'蛋炒饭'，然后把它吃个精光，缓解肚内空虚^_^。加班毕竟不比工作日，时间安排上有一定自主权，只要工作完成了，领导也不会说什么^_^。到公司的时候已经9点多了。很多来加班的已经到了。每天正式开始工作前都喜欢看看blog，看看有什么新闻发生，看看大家都在关注些什么。在自己的blog上居然发现这么一条评论，说我的blog像'天书'，最近英语笔记写了不少，也许是满屏的英语让这位'抽烟的大萝卜'感到不爽了，没办法，公司业务扩大，英语已经摆在了议事日程上来了，早学早受益亚^_^。上Bloglines看看其他人在五一节都在做甚么呢。Keso为我们带来了'劳动节的礼物' — Blogsome又一个Blog站点，看其主页还是挺清新简洁的，符合我的风格。苦咖啡豆想利用51尝试硬盘安装Ubuntu6，这与我也不谋而合，昨天朝秘书借了光驱，就准备在我的台式机上安装Ubuntu 5.10，Ubuntu光盘早于今年年初就收到了，惭愧的是至今仍未安装过。至于我订阅的其他Blogger们好像都去欣赏大自然的美好景色去了。

很多人都知道今天是沈阳世界园艺博览会的开园日，而且天公作美，今天沈城的天气格外的好，好像上个月的糟糕天气都是为今天'积德'的似的。估计今天的世博园要'爆棚'了，那是'红旗招展，人山人海'呀^_^

最后说一句：五一节你快乐，我工作。^_^

我也是直到最近才接触到'高可用性'这个词儿的，从我所在的项目需求角度出发，我理解'高可用性'就是在系统的外部依赖实体(如主数据库、主网络)等瘫痪了之后，系统仍然能正常的支撑业务的运行，当然系统自己宕掉了，那就没辙了^_^。高可用性设计实际上就是在系统自身完好的情况下如何考虑其外部实体的设计以保证系统能持续的运行支撑下去，起码从我现在正在做的项目的角度来说是可以这样理解的。

目前我们的系统的高可用性主要体现在对数据库的访问机制上。对于24×7小时运行的系统来说，数据库不可避免的需要采用一些容灾机制来保证数据的正确和不丢失或者是将损失减少到最低点。我们的系统采用双机热备的方式，一旦ACTIVE数据库宕掉，我们的系统就应该'自动'切换到STANDBY数据库上。这里就存在一个问题，到底如何切换，又如何在ACTIVE数据库恢复后，重新将数据库切换回到ACTIVE数据库呢？我个人从一开始就想这个切换过程应该对我们的系统保持透明，我们的系统能看到的只有一套用户名、密码和服务名并利用这套配置访问数据库，置于访问到哪一个数据库可由数据库那方来定，这样对于我们的系统来说实现起来会简单很多，但是我们的技术支持组给的答案却是做不到，需要我们的系统自己提供一套行之有效的数据库切换方案。经过研究我们提供这样一套办法：利用一个外部监视程序定时检测主数据库是否可用，这个状态检测程序一旦发现主数据库不可用，就通过一个简单内部通信协议发送一个消息包到我们的系统，我们的系统解析该消息包，做出相应的切换处理，并发送告警通知相关人员；当检测程序一旦发现主数据库可用了，发送另外一个消息包通知我们的系统数据库恢复了。我们的系统中有多个兄弟进程依赖数据库，每个进程都是单独与数据库建立session的，这样一旦需要切换数据库，我们这些可怜的进程就需要做同样的判断流程，可想而知代码中会存在多少的重复或相似的代码段，而且一旦流程修改我势必要修改多处，这样代码中的坏味道儿可就太浓了，势必应该进行重构，记得以前写过这么一篇'C语言也重构'，关于C语言重构的一些事项可以到那篇文章中查询。

灵光一闪！突然想到在Java组有数据库连接池的概念，我们可否效仿一下呢，我们也做一个这样的'数据库Session池'或者是一组抽象了的数据库session管理接口，这样对session的管理就集中起来了！session的管理接口负责判断是否需要切换和重新连接数据库，而这些切换操作对那些依赖数据库的进程来说是透明的。这样每个进程在每处理一条消息的时候都去调用一次open_session这样的接口，然后利用打开的session进行数据库操作即可。而open_session这个接口的实现也许要分两种情况：
1、在未切换数据库的情况下，使用原来已经存在的session即可，这里浪费的仅仅是一次条件判断而已；
2、在切换数据库的情况下，重新建立一个连到新数据库的session即可。

感觉这个方案可行，晚些儿时候再认真考虑一下，拿出一套可行方案。其实这里还要考虑这样一种情况也是可能性极其微小的情况，那就是两个数据库都宕了，这时候要考虑高可用性的话，那就该提供一些在没有数据库情况下的默认处理机制或者策略了。