项目分布式部署那些事(1):ONS消息队列、基于Redis的Session共享,开源共享

因业务发展需要现在的系统不足以支撑现在的用户量,于是我们在一周之前着手项目的性能优化与分布式部署的相关动作。

概况

现在的系统是基于RabbitHub(一套开源的开发时框架)和Rabbit.WeiXin(开源的微信开发SDK)开发的一款微信应用类系统,主要业务是围绕当下流行的微信元素,如:微官网、微商城、微分销、营销活动、会员卡等。

关于RabbitHub详情请戳:

.NET 平台下的插件化开发内核(Rabbit Kernel)

RabbitHub开源情况及计划

关于Rabbit.WeiXin详情请戳:

.NET平台下的微信SDK(Rabbit.WeiXin)开源发布

系统概况

现在的系统部署在两台物理服务器、一台云服务器上,其中云服务器部署着总站(用户信息的总站,单点登录)、ChunSunCloud(微信开放平台请求转发)项目,一台物理服务器为主要的负载服务器(数据库+web容器iis),另外一台则是一台热备服务器,主要在程序更新时使用。

新的部署方案

现在另购了两台云服务器,一台作为数据库服务器、另外一台则配合之前的一台云服务器担任着负载服务器的角色,因为现在迁移刚进行了一半,详细的部署情况会在这个阶段的事务完成之后再与大家分享。

这一次分享的内容

  1. 基于Redis的Session共享实现
  2. 基于阿里云开放消息服务(ons)的消息队列

开源地址:https://github.com/RabbitTeam/Distributed/

Session共享

在之前一直使用ASP.NET State service来解决Session共享的问题,无奈看事件日志时经常报出超时等异常,这一次花了一些时间使用了Redis实现了Session共享。

Distributed.SessionProvider.Redis

基于SessionStateStoreProviderBase无缝对接ASP.NET中的Session。

使用说明

Web.config中配置Reids服务器地址和SessionProvider

在<appSettings>下配置key为RedisServer的项,value为redis的服务器地址,如果修改了redis的默认端口号请加上端口号,例:

在<system.web>节点下配置SessionProvider

Type为:Distributed.SessionProvider.Redis.RedisSessionStateStoreProvider,Distributed.SessionProvider.Redis,例:

Sample:

在没有执行SetSession时GetSession是取不到值的。

在执行了SetSession之后GetSession是可以取到值的。

Code如下:

消息队列

之前的项目中使用了SignalR做了一个简单的消息队列,无奈不是非常稳定,所以这一次打算替换掉消息队列,目前使用了阿里云的ONS,该组件还没有与现有系统对接,只是做了实现所以后期改动性较大,大家按需使用。

Distributed.MessageQueue

一个抽象的消息队列,集成了Aliyun ONS <阿里云开放消息服务>。

在设计消息队列时由于不确定后期是否继续使用阿里云的ONS,所以在核心部分进行了抽象,不直接依赖阿里云ONS的SDK,只是做了适配,所以在后期变更消息队列时比较容易,有动手精神的童鞋可以自行扩展。

抽象部分的设计结构如下:

IMessageQueueFactory:消息队列工厂,用于创建 生产者和消费者实例。

IConsumer:消费者,提供消息订阅。

IProducer:生产者,消息发送。

IConnection:连接接口,主要用于保证连接只被开启一次和关闭一次。

整体设计:

Sample:

Consumer Code:

Producer Code:

写在最后

QQ群:384413261(RabbitHub)

Email:[email protected]

关于这篇文章中的内容:RabbitHub、微信SDK、Session共享、消息队列、分布式有兴趣的可以入群或者私信我一起探讨。

时间: 2024-10-27 03:28:42

项目分布式部署那些事(1):ONS消息队列、基于Redis的Session共享,开源共享的相关文章

.Net Core 商城微服务项目系列(七):使用消息队列(RabbitMQ)实现服务异步通信

RabbitMQ是什么,怎么使用我就不介绍了,大家可以到园子里搜一下教程.本篇的重点在于实现服务与服务之间的异步通信. 首先说一下为什么要使用消息队列来实现服务通信:1.提高接口并发能力.  2.保证服务各方数据最终一致.  3.解耦. 使用消息队列通信的有点就是直接调用的缺点,比如在直接调用过程中发生未知错误,很可能就会出现数据不一致的问题,这个时候就需要人工修补数据,如果有过这个经历的同学一定是可怜的,人工修补数据简直痛苦!!再比如高并发情况下接口直接挂点,这就更直白了,接口挂了,功能就挂了

【连载】redis库存操作,分布式锁的四种实现方式[三]--基于Redis watch机制实现分布式锁

一.redis的事务介绍 1. Redis保证一个事务中的所有命令要么都执行,要么都不执行.如果在发送EXEC命令前客户端断线了,则Redis会清空事务队列,事务中的所有命令都不会执行.而一旦客户端发送了EXEC命令,所有的命令就都会被执行,即使此后客户端断线也没关系,因为Redis中已经记录了所有要执行的命令. 2. 除此之外,Redis的事务还能保证一个事务内的命令依次执行而不被其他命令插入.试想客户端A需要执行几条命令,同时客户端B发送了一条命令,如果不使用事务,则客户端B的命令可能会插入

【结果很简单,过程很艰辛】记阿里云Ons消息队列服务填坑过程

Maybe 这个问题很简单,因为解决方法是非常简单,但填坑过程会把人逼疯,在阿里云ONS工作人员.同事和朋友的协助下,经过一天的调试和瞎捣鼓,终于解决了这个坑,把问题记下来,也许更多人在碰到类似问题的时候,会开放思路.当然不得不说,Ons的.NET接口还很不完善,甚至没有独立在Windos 2008/2012服务器测试过,希望官方加把力. 1.阿里云ONS介绍 ONS(Open Notification Service)即开放消息服务,是基于阿里开源消息中间件MetaQ(RocketMQ)打造的

.Net分布式架构(二):基于Redis的Session共享

一:Session简介 Session是什么呢?简单来说就是服务器给客户端的一个编号.当一台web服务器运行时,可能有若干个用户浏览正在运正在这台服务器上的网站.当每个用户首次与这台web服务器建立连接时,他就与这个服务器建立了一个Session,同时服务器会自动为其分配一个SessionID,用以标识这个用户的唯一身份.这个SessionID是由web服务器随机产生的一个由24个字符组成的字符串,我们会在下面的实验中见到它的实际样子. 二:Asp.Net中Session的集中模式和配置 (1)

[Java] 分布式消息队列(MQ)

概述 场景 服务解耦 削峰填谷 异步化缓冲:最终一致性/柔性事务 MQ应用思考点 生产端可靠性投递 消费端幂等:消息只能消费一次 高可用.低延迟.可靠性 消息堆积能力 可扩展性 业界主流MQ ActiveMQ:适合传统需求,并发性差 RabbitMQ:扩展性差 RocketMQ:扩展性强 Kafka:扩展性强,并发性强,可靠性差 技术选型 性能.优缺点.业务场景 集群架构模式,分布式.可扩展.高可用.可维护性 综合成本,集群规模,人员成本 未来的方向.规划.思考 ActiveMQ 介绍 JMS(

Netty构建分布式消息队列实现原理浅析

在本人的上一篇博客文章:Netty构建分布式消息队列(AvatarMQ)设计指南之架构篇 中,重点向大家介绍了AvatarMQ主要构成模块以及目前存在的优缺点.最后以一个生产者.消费者传递消息的例子,具体演示了AvatarMQ所具备的基本消息路由功能.而本文的写作目的,是想从开发.设计的角度,简单的对如何使用Netty,构建分布式消息队列背后的技术细节.原理,进行一下简单的分析和说明. 首先,在一个企业级的架构应用中,究竟何时需引入消息队列呢?本人认为,最经常的情况,无非这几种:做业务解耦.事件

WCF分布式开发步步为赢(13):WCF服务离线操作与消息队列MSMQ

之前曾经写过一个关于MSMQ消息队列的文章:WCF分布式开发必备知识(1):MSMQ消息队列 ,当时的目的也是用它来作为学习WCF 消息队列MSMQ编程的基础文章.在那篇文章里,我们详细介绍了MSMQ消息队列的基本概念.安装.部署.开发.调试等相关问题.今天我们来学习WCF分布式开发步步为赢(13):WCF服务离线操作与消息队列MSMQ.在WCF框架下使用MSMQ消息队列服务编程.  这里我会给出一个使用WCF MSMQ实现离线请求的DEMO示例程序. 全文结构是:[1]MSMQ基本概念[2]W

[转载] 基于Redis实现分布式消息队列

转载自http://www.linuxidc.com/Linux/2015-05/117661.htm 1.为什么需要消息队列?当系统中出现“生产“和“消费“的速度或稳定性等因素不一致的时候,就需要消息队列,作为抽象层,弥合双方的差异. 举个例子:业务系统触发短信发送申请,但短信发送模块速度跟不上,需要将来不及处理的消息暂存一下,缓冲压力. 再举个例子:调远程系统下订单成本较高,且因为网络等因素,不稳定,攒一批一起发送. 再举个栗子,交互模块5:00到24:00和电商系统联通,和内部ERP断开.

基于Redis实现分布式消息队列(3)

1.Redis是什么鬼? Redis是一个简单的,高效的,分布式的,基于内存的缓存工具. 假设好服务器后,通过网络连接(类似数据库),提供Key-Value式缓存服务. 简单,是Redis突出的特色. 简单可以保证核心功能的稳定和优异. 2.性能 性能方面:Redis是足够高效的. 和Memecached对比,在数据量较小大情况下,Redis性能更优秀. 数据量大到一定程度的时候,Memecached性能稍好. 简单结论:但总体上讲Redis性能已经足够好. // Ref: Redis性能测试