我在工作中的一个实际方案的分享，保留了思路与原理，去掉了具体系统实现的细节。

1、   方案要点

1.1         “数据变更通知消息”用于异步处理数据更新引起的后续操作，方案有如下特征：

1.1.1    延时性：消息会即时记录，但不一定即时处理，因此后续操作会有延时。

1.1.2    非事务性：消息产生后，无论是否处理消息、消息是否成功，都不会影响数据变更，不进行回滚操作。

1.1.3    持久性：消息产生后，系统重启等不会导致消息丢失。

1.2         系统中，如缓存更新等允许延迟的场景可使用该方案进行基于消息的缓存更新。

1.3         方案描叙了通知的应用点需要参考的内容和相关约定。

1.4         方案不包含应用点的具体实现，各应用点根据需要设计其实现。

2、   方案原理

2.1         获取数据变更消息

2.1.1    获取数据变更消息通过触发器实现，需要在所有需要监控的表上建立触发器。

2.1.2    触发器构造好消息数据后，调用“存储消息”的存储过程。

2.1.3    数据变更消息格式为XML，参见消息格式

2.2         存储消息

2.2.1    通过存储过程实现存储消息到总队列。

2.2.2    触发器直接调用该存储过程，实现将消息发送到消息总队列。

2.2.3    消息总队列收到消息时触发分发消息的存储过程的执行。

2.3         分发消息

2.3.1    通过存储过程实现分发消息。

2.3.2    存储过程从消息总队列获取消息，并调用各应用的分发存储过程：各应用的分发存储过滤消息函数后，将消息发送到应用对应的消息对列。

2.4         各应用使用数据变更消息

2.4.1    应用点从其对应的消息队列获取消息。

2.5         应用点根据自身逻辑进行后续处理。

3  消息格式

<Msg

DateTime="消息时间"

DBName="数据库名"

TableName="表名"

KeyField="主键名"

OperaType="操作类别"

Count="操作行数"

UpdateFileds="更新字段">

<Items>

<Item 字段名="字段值"字段名="字段值" />

<Item 字段名="字段值"字段名="字段值" />

…

</Items>

</Msg>

  消息说明：

•  DateTime：记录了消息产生的时间，格式如：2009-08-17T15:35:08.047
•  DBName：记录了发生数据变更的数据库名。
•  TableName：记录了发生数据变更的表名。
•  KeyField：记录了发生数据变更的表主键。
•  OperaType：记录了数据变更的类型，取值范围为{INSERT, UPDATE, DELETE}。
•  Count：记录了消息包含的数据变更行数。
•  UpdateFileds：记录了数据变更的字段，多个用逗号分隔，应仅在OperaType=”UPDATE”时参考该内容项，OperaType为其他值时该项为空。
•  /Items/Item：记录了发生数据变更的相关数据，记录形式为字段名与字段值。

4  处理流程图