fwq

在刚开始看RabbitMq权限的时候，分不清楚角色和权限（permission）的区别和用法，今天把我对它们的理解做一个总结。   角色 也可以理解为权限，但它只是针对管理RabbitMQ的权限，包括vhost、用户、exchange、queue、链接等。举个实际的例子：假设开启了rabbitmq_manage 的插件，通过set_user_tags 就可以赋予某个用户使用rabbitmq_manage的权限。 系统默认有5种角色：none、management、policymaker、monitoring、administrator none 不能访问 management plugin management 用户可以通过AMQP做的任何事外加： 列出自己可以通过AMQP登入的virtual hosts 查看自己的virtual hosts中的queues, exchanges 和 bindings 查看和关闭自己的channels 和 connections 查看有关自己的virtual hosts的“全局”的统计信息，包含其他用户在这些virtual hosts中的活动。 policymaker management可以做的任何事外加：…

今天对 RabbitMQ的cluster做个了结，感觉要学习的东西太多了，日后如果使用到了rabbit时，再来回顾吧。 RabbitMQ的cluster在普通模式下（注意是默认模式），吞吐大概在2w左右，但这种的模式不太实用，只要主节点一旦挂掉，整个集群就无法使用，这里不做过多的讨论。主要讨论它的镜像模式，这种模式需要设置vhost的策略（policy）   #将所有的队列设置为镜像模式 rabbitmqctl set_policy -p wanda ha-all "^" '{"ha-mode":"all"}' 这种模式下，吞吐在5000左右。但这种模式＋nginx可以实现高可用。  

官方的下载地址：https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/ 官方地址：http://zookeeper.apache.org/releases.html 目前的稳定版本是：zookeeper-3.4.9.tar.gz   安装步骤 # 官方下载是已编译的二进制包，解压后直接可以使用 # tar xzf zookeeper-3.4.9.tar.gz #在/usr/local/bin/目录下做了个软链接，方面操作 # ln -s /usr/local/zookeeper/bin/zkCli.sh ./zkCli # ln -s /usr/local/zookeeper/bin/zkEnv.sh ./zkEnv # ln -s /usr/local/zookeeper/bin/zkServer.sh ./zkServe  配置…

是不是要在标题的“作用”之前加上“重要”两个字，我犹豫了一下，zookeeper提供的功能是如此的重要，以至于如果你在应用中不使用它，早晚也会在你的应用中去实现zookeeper 的功能，所以，zookeeper值得你花（一点）时间去掌握。 zookeeper是为了“分布式”而诞生的，我反复在说“分布式”，并不是赶潮流，而是被潮流推着向前。在任何互联网生产应用中，哪怕你的公司规模小，访问量用一台服务器足够应付，仍然不能容忍当服务器故障时，没有备用的服务器可切换，这个称为“防止单点故障”，因为你至少要用两台服务器来防止单点故障，所以你已经在“分布式”的服务环境里。  我们来回顾上一次讲的话题，我把应用层的通用服务分为“读”服务和“写”服务，“读”服务用集群来实现高可用高性能，而“写”服务用单台服务器来保证事务顺序执行。 那么，“单台服务器”听上去好危险的样子，于是今天的主角登场，我们需要zookeeper。 你也许听到过，这种应用场景叫做master/slave，或者我更喜欢称为主/备模式，在这种场景下，我有两台服务器（主和备），任何情况下，只有“主”在工作，“备”是在主出现故障时，接替“主”来提供服务。在zookeeper的支持下，这一过程是这样实现的， Zookeeper提供目录和节点的服务，当我的两台服务器启动时，会在zookeeper的指定目录下创建对应自己的临时节点（这个过程称为“注册”），所谓临时节点，是靠心跳（定时向zookeeper服务器发送数据包）维系，当服务器出现故障（无法向zookeeper服务器发送数据包），zookeeper会删除临时节点。服务器向zookeeper注册时，zookeeper会分配序列号，我们认为序列号小的那个，就是“主”，序列号大的那个，就是“备”。 当我们的客户端（通常是web server）需要访问“写”服务时，需要连接zookeeper，获得指定目录下的临时节点列表，也就是已经注册的服务器信息，获得序列号小的那台“主”服务器的地址，进行后续的访问操作。以达到“总是访问主服务器”的目的。  当“主”服务器发生故障，zookeeper从指定目录下删除对应的临时节点，同时可以通知关心这一变化的所有客户端，高效且迅速的传播这一信息，你想一想，如果不是使用zookeeper，要自己实现这个功能，可没。。。那么简单（不许唱！） 我们为了消除单点故障而使用的主/备模式依赖zookeeper，那么zookeeper可不能有单点故障，所以zookeeper在诞生的时候，就是用集群的模式工作，用多台服务器来消除自身的单点故障隐患，怎么样，无可挑剔吧。 总结，在多核并行计算模式下，我认定基于消息传递的actor模型（源自erlang）是正确的编程方式，在actor模型下，可以简单实现基于服务层的串行操作，保证“写”操作的完整和一致。使用actor模型，需要用主/备的部署架构来消除单点故障，实现主/备的部署架构，最简单可靠的方法是用zookeeper。所以我现在的软件架构是这么推导出来的 高并发需求 -> 异步计算 (使用actor model) -> master/slave (使用zookeeper)