最近在開發一個輕量級ASP.NET MVC開發架構,需要加入日志記錄,郵件發送,短信發送等功能,為了保持子產品的獨立性,是以需要通過消息通信的方式進行處理,為了保持架構在部署,使用,二次開發過程中的簡易便捷性,是以沒有選擇傳統的MQ,而是基于Redis的訂閱釋出實作一個系統内部消息元件,話不多說,上碼!
資料結構定義
消息實體包含幾個部分,訂閱通道名稱,資訊頭,資訊體,資訊差異化額外資訊字典,資訊頭主要包含消息辨別,消息日期,資訊體包含資訊内容,資訊實體類型等
public class Message
{
public string MessageChannel { set; get; }
public MessageHead @MessageHead { set; get; }
public MessageBody @MessageBody { set; get; }
[JsonExtensionData]
public Dictionary<string,Object> @MessageExtra { set; get; }
public Message()
{
}
public void AddExtra(string Name, string Value)
{
if (@MessageExtra == null)
{
@MessageExtra = new Dictionary<string, object>();
}
@MessageExtra.Add(Name, Value);
}
public Object GetExtra(string Name)
{
return @MessageExtra[Name];
}
}
public class MessageHead
{
public string MessageID { set; get; }
public DateTime MessageDate { set; get; }
public MessageHead()
{
MessageID = CommonUtil.CreateCommonGuid();
MessageDate = DateTime.Now;
}
}
public class MessageBody
{
public string MessageJsonContent { set; get; }
public Type MessageMapperType { set; get; }
}
注:因為消息訂閱釋出傳遞過程中,我是通過Json序列化傳輸的,使用過程中可能需要一些額外的鍵值對資訊,這裡在對象中定義的是Dictinary對象,但是Dictinary本身是不支援序列化的,是以需要加上注解JsonExtensionData
訂閱通道聲明
我們需要達到的效果是,在系統啟動時,所有消息通道可以根據系統中的應用自動訂閱,這裡就需要一個注解來辨別我們的訂閱通道接收消息的實作類
[AttributeUsage(AttributeTargets.Class)]
public class MessageChanelAttribute : Attribute
{
private string _ChannleName;
public string ChannelName
{
get
{
return this._ChannleName;
}
set
{
this._ChannleName = value;
}
}
}

消息的個性化政策處理
Redis的三方庫我這裡使用的是StackExchange.Redis.dll,在消息訂閱時,需要為Channel指定接收到消息時的處理委托,我們在自動訂閱的過程中肯定也要收集好各類消息處理類并與Channel一一對應,這時候我們就需要一個基類FastDefaultMessageHandler,我們的具體的消息處理類繼承自FastDefaultMessageHandler,重寫處理方法即可
[Component]
[MessageChanelAttribute(ChannelName = "DefaultMessage")]
public class FastDefaultMessageHandler : IFastMessageHandle
{
[AutoWired]
public DBUtil @DBUtil;
public void HandleMessage(RedisChannel ChannelName, RedisValue Message)
{
FastExecutor.Message.Design.Message Entity = JsonConvert.DeserializeObject<FastExecutor.Message.Design.Message>(Message);
try
{
if (!CheckMessageIsConsume(Entity))
{
this.CustomHandle(Entity);
}
}
catch (Exception e)
{
StringBuilder ExceptionLog = new StringBuilder();
ExceptionLog.AppendFormat("異常Message所屬Channel:{0}", Entity.MessageChannel + Environment.NewLine);
ExceptionLog.AppendFormat("異常Message插入時間:{0}", Entity.MessageHead.MessageDate.ToString() + Environment.NewLine);
ExceptionLog.AppendFormat("異常Message内容:{0}", Message + Environment.NewLine);
ExceptionLog.AppendFormat("異常資訊:{0}", e.Message + Environment.NewLine);
LogUtil.WriteLog("Logs/MessageErrorLog", "log_", ExceptionLog.ToString() + Environment.NewLine);
ExceptionLog.AppendFormat("========================================================================================================================================================================" + Environment.NewLine);
MessageACK.MoveMessageToExceptionChannel(Entity.MessageChannel, Entity);
}
finally
{
MessageACK.ConfirmMessageFinish(Entity.MessageChannel, Entity.MessageHead.MessageID);
}
}
public virtual void CustomHandle(FastExecutor.Message.Design.Message @Message)
{
}
public virtual bool CheckMessageIsConsume(FastExecutor.Message.Design.Message @Message)
{
return false;
}
}
其中的HandleMessage方法就是我們在訂閱Channel時對應的委托,會調用類中的CustomHandle的虛方法,子類繼承重寫該方法就會基于多态進行政策調用,CheckMessageIsConsume方法是用于确認消息是否重複消費的,也可以被重寫,下面看一個通路日志類的執行個體,使用MessageChanelAttribute标注聲明該實作類需要訂閱釋出的Channel名稱為Visit,CustomHandle方法中實作了插入資料庫操作,CheckMessageIsConsume方法判斷該條日志資料是否已消費(已經存在于資料庫)
[MessageChanelAttribute(ChannelName = "Visit")]
public class VisitLog : FastDefaultMessageHandler
{
public override void CustomHandle(Message.Design.Message Message)
{
Frame_VisitLog LogEntity = JsonConvert.DeserializeObject<Frame_VisitLog>(Message.MessageBody.MessageJsonContent);
@DBUtil.Insert(LogEntity);
base.CustomHandle(Message);
}
public override bool CheckMessageIsConsume(Message.Design.Message Message)
{
Frame_VisitLog LogEntity = JsonConvert.DeserializeObject<Frame_VisitLog>(Message.MessageBody.MessageJsonContent);
DBRow Row = new DBRow("Frame_VisitLog", "RowGuid", LogEntity.RowGuid);
if (Row.IsExist())
{
return true;
}
else
{
return false;
}
}
}
消息自動訂閱
我們希望系統在啟動時就尋找出定義好Channel和實作類,自動實作訂閱,這裡就需要用到IOC容器,啟動系統時将所有的消息處理類放入容器中,在自動訂閱時全部取出來,根據消息處理類中聲明的Channel名稱進行自動訂閱
public void Init()
{
List<Type> HandlerTypeList = InjectUtil.Container.GetRegistType(typeof(IFastMessageHandle));
foreach (Type HandlerType in HandlerTypeList)
{
MessageChanelAttribute Channel = Attribute.GetCustomAttribute(HandlerType, typeof(MessageChanelAttribute)) as MessageChanelAttribute;
RedisUtil.Subscribe(Channel.ChannelName, ((FastDefaultMessageHandler)InjectUtil.Container.Resolve(HandlerType)).HandleMessage);
}
}
注:
1.這裡的IOC容器是我自己實作的,位址:https://gitee.com/code2roc/FastIOC,大家可以用AutoFac代替
2.RedisUtil是對StackExchange.Redis.dll封裝的處理類,位址:https://gitee.com/code2roc/FastUtil
消息發送
消息隻需要調用Redis的釋出方法即可,将Channel名稱與定義好的資料實體類傳入,序列化為Json
public void SendMessage<T>(string ChannleName, T CustomMessageEntity, Dictionary<string, string> ExtraData = null)
{
FastExecutor.Message.Design.Message MessageEntity = new Design.Message();
MessageEntity.MessageChannel = ChannleName;
MessageHead Head = new MessageHead();
MessageBody Body = new MessageBody();
Body.MessageMapperType = typeof(T);
Body.MessageJsonContent = JsonConvert.SerializeObject(CustomMessageEntity);
MessageEntity.MessageHead = Head;
MessageEntity.MessageBody = Body;
if (ExtraData != null)
{
foreach (var item in ExtraData)
{
MessageEntity.AddExtra(item.Key, item.Value);
}
}
RedisUtil.Publish(ChannleName, MessageEntity);
MessageACK.CopyMessageToACKList(ChannleName, MessageEntity);
}
消息确認與存儲
Redis作訂閱釋出模式作為消息元件的問題有兩方面
問題:消息消費完沒有确認機制
解決方案
基于Redis的Hash存儲方式建立一個消息存儲字段,在發送消息時拷貝到消息Hash字典中,消費完畢後再删除,對應SendMessage中的MessageACK.CopyMessageToACKList方法和FastDefaultMessageHandler中的MessageACK.ConfirmMessageFinish方法,本質就是對Hash字典的增加與删除功能
問題:消息處理端挂了再次重新開機消息會丢失
确認機制已經保證了消息即使沒有被消費完但是處理端當機消息也不會丢失,需要注意的是,消息沒有丢失僅僅是Hash字典中有存儲,但是消息通道中不存在了,是以我們在系統每次啟動時掃描這個Hash字典,重新釋出消息到Channel,這樣可能導緻重複消費,是以需要靠FastDefaultMessageHandler中的CheckMessageIsConsume方法判斷,同時消息處理者本身處理異常我們也需要記錄下來,比如發短信供應商接口有問題,消息處理異常會進入Redis的ChannelException通道,我們可以根據需求實作一個可視化界面決定是否通過手動恢複
最後
Message元件相關代碼位址:https://gitee.com/code2roc/FastExecutor/tree/master/code/FastExecutor/FastExecutor.Message
存在不足問題:如果消息是單純記錄日志問題,沒辦法确認消息是否消費了
如果大家有什麼好的建議,可留言一起交流學習,共同進步