系统的监控体系

1.监控

系统硬件网络层面利用zabbix,top,netstat这些工具监控

2.日志

程序内部日志收集,内嵌日志组件,也可并入分布式的日志收集系统

3.APM:应用性能监控

单个部署应用的性能监控,从业务层面上更细,有开源的内嵌代码的方式,也有嵌入第三方的监控还能报警

zookeeper基础

0.介绍:分布式协调系统。类似于linux文件系统的数据存储结构!!!
a)选举leader端口:3888,数据通讯端口:2888,默认客户连接端口:2181.
b)剩余节点总数大于总数据的1/2时,才正常运行
c)选择leaderf规则(二阶段/2pc提交):
d)一些名词:leader,follow,leading,following,ZNode,Watcher.
e)leader==》读写,follower==>只负责读
1.Zookeeper安装(先安装java)有三种方式:安装的数量建议是单数。
单机模式/standalone:Zookeeper运行一台机器上
伪集群模式:一台物理机上运行多个zookeeper实例
集群模式:Zookeeper运行一个集群上,适合生产环境
2.布置standalone模式:
a)修改环境:增加zk_home路径;增加bin目录路径
ZOOKEEPER_HOME=/usr/local/zookeeper-3.4.14
export ZOOKEEPER_HOME
PATH=$ZOOKEEPER_HOME/bin:$PATH
export PATH

b)修改配置文件:修改数据保存路径;指定ZK的主机;指定主机的myid.
dataDir=/usr/local/zookeeper-3.4.14/tmp
server.1=zk_31:2888:3888

vi /usr/local/zookeeper-3.4.14/tmp/myid
//输入1,与配置文件中的server.1对应

c)启动
zkServer.sh start
d)使用
zkServer.sh status//查看状态,stop,关闭
zkCli.sh //不加参数,默认登录本机zk

ls / //查根节点,允许多个根节点
ls /mydata //查看mydata节点下的子节点
create /mydata helloworld //创建/mydata节点,数据是helloworld

3.应用:
a)分布式锁(与redis实现的区别,setnx)
b)负载均衡:利用树形数据结构和watch原理,自己代码实现
4.一致性:
a)强一致性:当更新操作完成之后,任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的,就是用户上一次写什么,下一次就保证能读到什么。根据 CAP 理论,这种实现需要牺牲可用性。在分布式中,一般是实现不了的,所以在单体应用层中,可以使用更新锁或者插入锁,当查询时必须等解锁后才能读到数据。
b)弱一致性: 系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后,不承诺立即可以读到最新写入的值,也不会具体的承诺多久之后可以读到。大多数分布式都是如此,存在脏数据,需要优化。
c)最终一致性:对弱一致性的优化结果。
弱一致性的特定形式。系统保证在没有后续更新的前提下,系统最终返回上一次更新操作的值。在没有故障发生的前提下,不一致窗口的时间主要受通信延迟,系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。
最终一致性的解决方案有:MQ(发布订阅消息,队列消息),分布式事务(要不全部成功,要不全部失败,也是首先基于mq的发布订阅事务消息实现),还有补偿模式,校对模式,缓存一致性模式


附多节点配置:
在每台节点的配置上增加
“`
server.1=zk_31:2888:3888
server.2=zk_32:2888:3888
server.3=zk_33:2888:3888


myid文件的内容分别为1,2,3
“`

kafka基础

0.介绍:分布式订阅消息系统
1.名词:
a)Topic:特指kafka处理的消息源
b)Partition:分区,Topic物理上的分组,一个Topic可以有多个Partition,每个Partition是一个有序的队列
c)Message:通信的基本单位
d)Producer:生产者。向kafka的一个Topic发布的过程叫生产
e)Consumer:消费者。订阅Topic并处理其发布的消息的过程叫消费。
f)Broker:缓存代理节点。Kafka集群中的一台或者多台服务器。
g):leader==>负责读写,follower 负责同步,只负责备份
2.应用场景:
a)Messge消息系统
b)网站活性跟踪
c)日志收集中心
3.Zookeeper:
4.布置方式:
a)单broker:
b)单机多broker(伪分布式):
c)多机多broker(真分布式):
5.布置单机模式:
a)安装JAVA
“`
JAVA_HOME=/usr/local/java/jdk1.8.0_231
export PATH

PATH=$JAVA_HOME/bin:$PATH
export PATH

“`
b)设置kakfa的PATH

c)修改配置
“`
broker.id=0 //单机模式不用改

log.dirs=/usr/local/kafka/kafka_2.12-2.4.0/logs
zookeeper.connect=zk_31:2181,zk_32:2181,zk_33:2181 //设置zk
d)启动:启动后,会在zk创建很多目录数据
bin/kafka-server-start.sh config/server.properties &
e)操作
bin/kafka-topics.sh –create –zookeeper zk_31:2181 –replication-factor 1 –partitions 3 –topic mydemo1 //创建一个topic,指定三个分区,一个副本
“`
6.kafka与其他mq区别
7.broker
微信截图_20200302172356
8.kafka负载均衡分配数据

Kafka中ZooKeeper的用途

Kafka中ZooKeeper的用途:正如ZooKeeper用于分布式系统的协调和促进,Kafka使用ZooKeeper也是基于相同的原因。ZooKeeper用于管理、协调Kafka代理。每个Kafka代理都通过ZooKeeper协调其它Kafka代理。当Kafka系统中新增了代理或者某个代理故障失效时,ZooKeeper服务将通知生产者和消费者。生产者和消费者据此开始与其它代理协调工作。Kafka整体系统架构所示。

CloudStack和OpenStack该如何选择

http://cloud.51cto.com/art/201507/483592.htm

那么OpenStack和CloudStack对于不同公司意味着什么呢?
我曾经和很多大公司进行过交流,也和不少从OpenStack转向CloudStack的朋友进行过交流。对于大公司来说,他们的研发能力强,对于云计算有自己的产品或服务要出售,他们会倾向于选择一个半成品的软件,自己进行hack。这些公司认为OpenStack就好像是一个开发框架,自己可以在里面做很多的定制开发。所以,如果准备选择OpenStack,请做好hack的准备。
如果公司是偏向于项目集成的,并不想在底层做太多的投入,只希望有一个稳定的底层,自己根据用户的业务场景进行二次开发,那么CloudStack 很适合你。CloudStack的底层功能已经做的很完善了,目前CloudStack的落地项目很多,功能和稳定性上更适合商用。国内的公司只需要做一些界面的开发,结合客户的业务做一些定制即可。相对来说,开发难度低很多。国内的java程序员要比python程序员多很多,招人也方便。