windows下安装配置mongodb

一、mongodb安装配置 下载mongodb (官方下载地址http://www.mongodb.org/downloads),解压缩到自己想要安装的目录,这里是g:\mongodb;如果是安装版,设置好安装路径后,一直Next直到安装结束。 创建文件夹g:\mongodb\data\db     用于放数据 创建文件夹g:\mongodb\logs\    用于日志 创建文件夹g:\mongodb\etc\     放配置文件 在g:\mongodb\logs文件夹下创建一个日志文件mongodb.log 在g:\mongodb\etc文件夹下创建一个日志文件mongodb.conf 在mongodb.conf文件中配置: dbpath=G:\mongodb\data\db #数据库路径 logpath=G:\mongodb\logs\mongodb.log…

Continue Reading →

ActiveMQ版本的安装部署

Windows平台 1, 保证电脑上安装了jdk6以上版本的java,并配置了好环境变量 ;   2, 官方下载地址:http://activemq.apache.org/download-archives.html ,这里使用 5.8.0   3, 解压缩下载好的 apache-activemq-5.8.0-bin.zip .   4, bin目录下由win32/ win64可以供选择. 5, 我这里是进入 win64 ,运行activemq.bat…

Continue Reading →

Windows下ZooKeeper的安装配置

ZooKeeper安装配置 在下面,先搭建一个单机模式的的ZooKeeper环境。 首先从将zookeeper下载下来。本人在这里下载的是3.4.9,下载地址在这里(http://mirror.bit.edu.cn/apache/zookeeper/) 下载后再将其解压到指定的目录中,我是解压到D盘中的,如下图所示: 复制zookeeper-3.4.9\conf目录下的zoo_sample.cfg文件改名为zoo.cfg: 在zookeeper-3.4.9目录下新建两个文件夹,分别是data和logs。 修改zoo.cfg配置文件: 配置文件简单解析: 1、tickTime:基本事件单元,以毫秒为单位。这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔,它用来控制心跳和超时,也就是每个 tickTime 时间就会发送一个心跳。默认情况下最小的会话超时时间为两倍的 tickTime。 2、clientPort:监听客户端连接的端口。这个端口就是客户端连接 Zookeeper 服务器的端口,Zookeeper 会监听这个端口,接受客户端的访问请求。 3、dataDir:顾名思义就是 Zookeeper…

Continue Reading →

高性能优秀的服务框架-dubbo介绍

“传统架构”:很多年前,刚学完JavaWeb开发的我凭借一人之力就开发了一个网站,网站 所有的功能和应用都集中在一起,方便了我的开发同时也节省了成本。但是后来我的网站访问流量突然加大,我通过不断增加服务器来提高并发量,但是我发现随着服务器的增加服务能力先增加后下降。 不能通过硬件的方式解决问题的我,思考如何通过软件解决这个问题。 “分布式架构”:后来我按照功能点把系统拆分,拆分成独立的功能。单独为某一个节点添加服务器。通过系统之间配合完成整个业务逻辑。但是随着我的网站功能的日益完善,我发现各个模块有一些通用的业务逻辑无法共用,这样可不好,这时候我就在考虑为啥部直接来个面向服务呢??? “面向服务架构”:我把工程拆分成服务层、表现层两个工程。服务层中包含业务逻辑,只需要对外提供服务即可。表现层只需要处理和页面的交互,业务逻辑都是调用服务层的服务来实现。这样我的网站不光开发效率快,而且在扩展和升级相关服务的时候更加灵活。 说了这么多“废话”,那么什么是dubbo?为什么要用dubbo呢? 什么是dubbo? Dubbo是 阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 Spring框架无缝集成。 上面我们提到了RPC,现在我们来理解一下RPC的一些相关概念。之前学习过操作系统的同学在进程那一章也会接触到这个东西。 RPC(Remote Procedure Call)—远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在,如TCP或UDP,为通信程序之间携带信息数据。在OSI网络通信模型中,RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。 RPC采用客户机/服务器模式。请求程序就是一个客户机,而服务提供程序就是一个服务器。首先,客户机调用进程发送一个有进程参数的调用信息到服务进程,然后等待应答信息。在服务器端,进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达,服务器获得进程参数,计算结果,发送答复信息,然后等待下一个调用信息,最后,客户端调用进程接收答复信息,获得进程结果,然后调用执行继续进行。 既然有http请求为什么还要用rpc调用呢??? 良好的rpc调用是面向服务的封装,针对服务的可用性和效率等都做了优化。单纯使用http调用则缺少了这些特性。 dubbo的一些相关资源…

Continue Reading →

消息队列ActiveMQ的使用详解

JMS 1. JMS基本概念 JMS(JAVA Message Service,java消息服务)是java的消息服务,JMS的客户端之间可以通过JMS服务进行异步的消息传输。JMS(JAVA Message Service,java消息服务)API是一个消息服务的标准或者说是规范,允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信耦合度更低,消息服务更加可靠以及异步性。 2. JMS五种不同的消息正文格式 JMS定义了五种不同的消息正文格式,以及调用的消息类型,允许你发送并接收以一些不同形式的数据,提供现有消息格式的一些级别的兼容性。 StreamMessage — Java原始值的数据流 MapMessage–一套名称-值对 TextMessage–一个字符串对象 ObjectMessage–一个序列化的 Java对象 BytesMessage–一个字节的数据流 3.JMS两种消息模型…

Continue Reading →

消息队列深入解析

消息队列和消息 “消息队列”(Message queue)是在消息的传输过程中保存消息的容器。“消息” 是在两台计算机间传送的数据单位。消息可以非常简单,例如只包含文本字符串;也可以更复杂,可能包含嵌入对象。 常见的消息队列有那些? 当前使用较多的消息队列有RabbitMQ、ActiveMQ、RocketMQ、Kafka等等,我们之前提高的redis数据库也可以实现消息队列,不过不推荐,redis本身设计就不是用来做消息队列的。 使用消息队列的场景和好处 《大型网站技术架构》第四章和第七章均有提到消息队列对应用性能及扩展性的提升。 1.通过异步处理提高系统性能 如上图,在不使用消息队列服务器的时候,用户的请求数据直接写入数据库,在高并发的情况下数据库压力剧增,使得响应速度变慢。但是在使用消息队列之后,用户的请求数据发送给消息队列之后立即 返回,再由消息队列的消费者进程从消息队列中获取数据,异步写入数据库。由于消息队列服务器处理速度快于数据库(消息队列也比数据库有更好的伸缩性),因此响应速度得到大幅改善。通过以上分析我们可以得出消息队列具有很好的削峰作用的功能——即通过异步处理,将短时间高并发产生的事务消息存储在消息队列中,从而削平高峰期的并发事务。 举例:在电子商务一些秒杀、促销活动中,合理使用消息队列可以有效抵御促销活动刚开始大量订单涌入对系统的冲击。如下图所示: 因为用户请求数据写入消息队列之后就立即返回给用户了,但是请求数据在后续的业务校验、写数据库等操作中可能失败。因此使用消息队列进行异步处理之后,需要适当修改业务流程进行配合,比如用户在提交订单之后,订单数据写入消息队列,不能立即返回用户订单提交成功,需要在消息队列的订单消费者进程真正处理完该订单之后,甚至出库后,再通过电子邮件或短信通知用户订单成功,以免交易纠纷。这就类似我们平时手机订火车票和电影票。 2.降低系统耦合性 我们知道模块分布式部署以后聚合方式通常有两种:1.分布式消息队列和2.分布式服务。 先来简单说一下分布式服务: 目前使用比较多的用来构建SOA(Service Oriented Architecture面向服务体系结构)的分布式服务框架是阿里巴巴开源的Dubbo.如果想深入了解Dubbo的可以看我写的关于Dubbo的这一篇文章:《高性能优秀的服务框架-dubbo介绍》:juejin.im/post/5acade… 再来谈我们的分布式消息队列:…

Continue Reading →

ZooKeeper原理与应用

简介 ZooKeeper是一个开源的分布式协调服务,由雅虎创建,是Google Chubby的开源实现。ZooKeeper的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一系列简单易用的接口提供给用户使用。 ZooKeeper是一个典型的分布式数据一致性的解决方案。分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。ZooKeeper可以保证如下分布式一致性特性。 顺序一致性 从同一个客户端发起的事务请求,最终将会严格按照其发起顺序被应用到ZooKeeper中。 原子性 所有事务请求的结果在集群中所有机器上的应用情况是一致的,也就是说要么整个集群所有集群都成功应用了某一个事务,要么都没有应用,一定不会出现集群中部分机器应用了该事务,而另外一部分没有应用的情况。 单一视图 无论客户端连接的是哪个ZooKeeper服务器,其看到的服务端数据模型都是一致的。 可靠性 一旦服务端成功地应用了一个事务,并完成对客户端的响应,那么该事务所引起的服务端状态变更将会被一直保留下来,除非有另一个事务又对其进行了变更。 实时性 通常人们看到实时性的第一反应是,一旦一个事务被成功应用,那么客户端能够立即从服务端上读取到这个事务变更后的最新数据状态。这里需要注意的是,ZooKeeper仅仅保证在一定的时间段内,客户端最终一定能够从服务端上读取到最新的数据状态。 基本概念 本节将介绍ZooKeeper的几个核心概念。这些概念贯穿于之后对ZooKeeper更深入的讲解,因此有必要预先了解这些概念。 集群角色 在ZooKeeper中,有三种角色: Leader Follower…

Continue Reading →