MB+MQ开发技术实例(零)环境搭建

MB+MQ开发技术实例(零)环境搭建

(一)准备工作:
1.依次安装 DB2、MQ、MB、MessageBrokersToolkit。

2.启动 DB2、WebSphere MQ。

3.打开 IBM WebSphere Message Brokers 6.0 命令控制台。

(二)基础参数:
1.系统登陆账户: 用户名 Admin 密码Admin
注意:系统账户名不多于8个字符,权限为系统管理员

2.DB2 数据库:用户名:Admin密码:Admin.

(三)开始用命令行创建代理:
1. mqsicreatedb LROI -i Admin -a Admin -p 50000 -e “DB2”
命令选项:
“databaseName”是要创建的数据库的名称(此为LROI)
可选:
“-i serviceUserID”应该运行 DatabaseInstanceMgr 的用户标识。
“-a servicePassword”DatabaseInstanceMgr 用户标识的密码。
“-p portNumber”DatabaseInstanceMgr 应该使用的端口号(缺省值=1527)
“-e dbType”要使用的数据库类型,当前报告为:“DB2”或“Derby”

这里写图片描述

  1. mqsicreatebroker LORI_BROKER -i Admin -a Admin -q LORI_QM -n LORI -u Admin -p Admin –j
    命令选项:
    “brokerName”要创建的代理名称(此为LORI_BROKER)
    “-i serviceUserId”运行代理所使用的用户标识
    “-a servicePassword”代理用户标识的密码
    “-q queueManagerName”代理将使用的 WebSphere MQ 队列管理器。如果不存在,则创建它。
    “-n dataSourceName”代理的数据库名称
    “-u dataSourceUserId”代理用于访问其数据库的用户标识
    “-p dataSourcePassword”代理数据库用户标识的密码
    “-s unsQMgrName”用户名称服务器的 WebSphere MQ 队列管理器
    “-j”为代理启用发布/预订访问控制

这里写图片描述

  1. mqsicreateconfigmgr LORI_ConfigMgr -i Admin -a Admin -q LORI_QM
    命令选项
    “configMgrName”配置管理器的名称(在 Windows 上可被省略)(此为LORI_ConfigMgr)
    “-i serviceUserId”运行配置管理器所使用的用户标识
    “-a servicePassword”配置管理器用户标识的密码
    “-q queueManagerName”配置管理器将使用的 WebSphere MQ 队列管理器(如果不存在,则创建它)

这里写图片描述

  1. mqsicreateusernameserver -i Admin -a Admin -q LORI_QM
    命令选项:
    “-i serviceUserId”运行用户名称服务器所使用的用户标识
    “-a servicePassword”用户名称服务器用户标识的密码
    “-q queueManagerName”用户名称服务器将使用的 WebSphere MQ 队列管理器(如果不存在,则创建它)
    这里写图片描述

  2. 到此创建代理成功。下面开始用mqsistart命令启动代理。
    这里写图片描述

  3. 创建该代理的监听器。
    启动 WebSphere MQ 资源管理器。
    -> 高级 -> 右键点击侦听器 -> 新建 -> TCP 侦听器…
    名称: LORI.LISTENER.TCP
    点击”下一步”
    控件:队列管理器启动
    端口:1414
    IP 地址:空
    点击”完成”
    -> 启动 TCP 侦听器 LORI.LISTENER.TCP
    这里写图片描述
    这里写图片描述

  4. 右键点击【LORI_QM】选择【远程管理】会自动创建缺省的通道。
    这里写图片描述

### 特性对比 Apache Kafka 和传统消息队列 (MQ) 系统在多个方面存在显著差异。对于性能表现,在单服务器级别机器和单一主题的情况下,Luxun 消息系统的吞吐量可以远超 100 MB/s[^1]。尽管这里提到的是 Luxun 的数据,但 Apache Kafka 同样作为分布式流处理平台也具备类似的高性能特点。 #### 高可用性和持久化支持 - **Kafka**: 设计之初就考虑到了高可用性的需求,通过复制机制确保即使部分节点失效也不会丢失数据;它是一个持久化的消息系统,能够可靠地存储大量未被消费的消息直到它们过期。 - **传统 MQs**: 大多数传统的消息中间件同样提供了一定程度上的可靠性保障措施,比如事务提交确认、死信队列等功能来增强其健壮性。然而,不是所有的传统 MQ 都能像 Kafka 这样天然支持大规模集群部署下的高效副本管理与自动恢复能力。 #### 扩展能力和伸缩性 - **Kafka**: 支持水平扩展,随着业务增长可轻松增加新的 broker 节点而无需停机维护,这使得它可以应对海量的数据传输任务并保持较低延迟。 - **传统 MQs**: 可能会面临更复杂的配置过程才能实现相似级别的横向扩容效果,并且某些产品可能并不完全适合实时性强的应用场景。 #### 数据模型和编程接口 - **Kafka**: 基于发布/订阅模式构建,允许生产者向特定的主题发送记录,消费者可以从这些主题读取消息。此外还提供了丰富的 API 接口以及多种语言客户端库的支持。 - **传统 MQs**: 往往采用更为经典的点对点通信方式或是广播形式分发信息给接收端应用实例,API 层面的设计也可能更加注重企业级集成特性而非大数据分析领域的需求。 ### 使用案例区别 由于上述技术特性的不同之处,两者适用于不同类型的工作负载: - 当应用程序需要处理极高频率的日志收集、监控指标上报或者是社交媒体平台上产生的用户行为事件追踪时,通常会选择 Kafka 来搭建相应的基础设施架构; - 对于那些侧重于服务间异步调用协调、命令请求响应交互等操作的企业内部 IT 架构,则更多依赖成熟的商业版或开源版本的传统 MQ 解决方案完成相应功能模块之间的解耦合工作。 ```python from kafka import KafkaProducer producer = KafkaProducer(bootstrap_servers='localhost:9092') future = producer.send('my-topic', b'raw_bytes') result = future.get(timeout=60) print(result.topic, result.partition, result.offset) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值