Python Web后台
平衡二叉树 B树 B+树
https://zhuanlan.zhihu.com/p/27700617
平衡二叉树
(1)非叶子节点最多拥有两个子节点;
(2)非叶子节值大于左边子节点、小于右边子节点;
(3)树的左右两边的层级数相差不会大于1;
(4)没有值相等重复的节点;
https://www.cnblogs.com/xueqiuqiu/articles/8779029.html
B树
B树相对于平衡二叉树的不同是,每个节点包含的关键字增多了,特别是在B树应用到数据库中的时候,数据库充分利用了磁盘块的原理(磁盘数据存储是采用块的形式存储的,每个块的大小为4K,每次IO进行数据读取时,同一个磁盘块的数据可以一次性读取出来)把节点大小限制和充分使用在磁盘快大小范围;把树的节点关键字增多后树的层级比原来的二叉树少了,减少数据查找的次数和复杂度;
B+树
1、B+树的层级更少:相较于B树B+每个非叶子节点存储的关键字数更多,树的层级更少所以查询数据更快;
2、B+树查询速度更稳定:B+所有关键字数据地址都存在叶子节点上,所以每次查找的次数都相同所以查询速度要比B树更稳定;
3、B+树天然具备排序功能:B+树所有的叶子节点数据构成了一个有序链表,在查询大小区间的数据时候更方便,数据紧密性很高,缓存的命中率也会比B树高。
4、B+树全节点遍历更快:B+树遍历整棵树只需要遍历所有的叶子节点即可,,而不需要像B树一样需要对每一层进行遍历,这有利于数据库做全表扫描。
B树相对于B+树的优点是,如果经常访问的数据离根节点很近,而B树的非叶子节点本身存有关键字其数据的地址,所以这种数据检索的时候会要比B+树快。
事务
事务应该具有4个属性:原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。
1.原子性(atomicity)一个事务是一个不可分割的工作单位,事务中包括的操作要么都做,要么都不做。
2.一致性(consistency)事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。
3.隔离性(isolation)一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的,并发执行的各个事务之间不能互相干扰。
4.持久性(durability)持久性也称永久性(permanence),指一个事务一旦提交,它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。
flask,django,tornado
Tornado
传说中实现高并发、高性能的框架。Tornado的全称是Torado Web Server,可用作Web服务器,同时也是一个Python Web的开发框架。
Tornado两大核心模块:
iostream :对非阻塞式的 socket 的简单封装,用来处理 socket 的异步读写
ioloop :核心的 I/O 循环。基于 epoll,可以高效的响应网络事
flask适合用于小型应用开发;如果开发团队能力强,也可以用来做大中型应用
django适合应用用于访问量不大的大中型应用
tornado适合用于开发长连接多的web应用。比如股票信息推送、网络聊天等。
异步
消息队列
主要作用:解耦、异步、削峰
解耦:扩展系统只用通过消息队列,而不用额外开发适应系统
异步:发出任务不等待回调
削峰
缺点
系统可用性降低:你想呀,本来其他系统只要运行好好的,那你的系统就是正常的。现在你非要加入个消息队列进去,那消息队列挂了,你的系统不是呵呵了。因此,系统可用性会降低
系统复杂性增加:加入了消息队列,要多考虑很多方面的问题,比如:一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此,需要考虑的东西更多,刺痛复杂性增大。
ActiveMQ RabbitMQ RocketMQ kafka四种消息队列对比
综合上面的材料得出以下两点:
(1)中小型软件公司,建议选RabbitMQ.一方面,erlang语言天生具备高并发的特性,而且他的管理界面用起来十分方便。正所谓,成也萧何,败也萧何!他的弊端也在这里,虽然RabbitMQ是开源的,然而国内有几个能定制化开发erlang的程序员呢?所幸,RabbitMQ的社区十分活跃,可以解决开发过程中遇到的bug,这点对于中小型公司来说十分重要。不考虑rocketmq和kafka的原因是,一方面中小型软件公司不如互联网公司,数据量没那么大,选消息中间件,应首选功能比较完备的,所以kafka排除。不考虑rocketmq的原因是,rocketmq是阿里出品,如果阿里放弃维护rocketmq,中小型公司一般抽不出人来进行rocketmq的定制化开发,因此不推荐。
(2)大型软件公司,根据具体使用在rocketMq和kafka之间二选一。一方面,大型软件公司,具备足够的资金搭建分布式环境,也具备足够大的数据量。针对rocketMQ,大型软件公司也可以抽出人手对rocketMQ进行定制化开发,毕竟国内有能力改JAVA源码的人,还是相当多的。至于kafka,根据业务场景选择,如果有日志采集功能,肯定是首选kafka了。具体该选哪个,看使用场景。
kafka:
1 broker
Kafka 集群包含一个或多个服务器,服务器节点称为broker。
broker存储topic的数据。如果某topic有N个partition,集群有N个broker,那么每个broker存储该topic的一个partition。
如果某topic有N个partition,集群有(N+M)个broker,那么其中有N个broker存储该topic的一个partition,剩下的M个broker不存储该topic的partition数据。
如果某topic有N个partition,集群中broker数目少于N个,那么一个broker存储该topic的一个或多个partition。在实际生产环境中,尽量避免这种情况的发生,这种情况容易导致Kafka集群数据不均衡。
2 Topic
每条发布到Kafka集群的消息都有一个类别,这个类别被称为Topic。(物理上不同Topic的消息分开存储,逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处)
类似于数据库的表名
3 Partition
topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的,不同partition间的数据丢失了数据的顺序。如果topic有多个partition,消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下,需要将partition数目设为1。
4 Producer
生产者即数据的发布者,该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后,broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息,存储到一个partition中,生产者也可以指定数据存储的partition。
5 Consumer
消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。
6 Consumer Group
每个Consumer属于一个特定的Consumer Group(可为每个Consumer指定group name,若不指定group name则属于默认的group)。这是kafka用来实现一个topic消息的广播(发给所有的consumer)和单播(发给任意一个consumer)的手段。一个topic可以有多个CG。topic的消息会复制-给consumer。如果需要实现广播,只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。
rabbitmq
Broker:它提供一种传输服务,它的角色就是维护一条从生产者到消费者的路线,保证数据能按照指定的方式进行传输,
Exchange:消息交换机,它指定消息按什么规则,路由到哪个队列。
Queue:消息的载体,每个消息都会被投到一个或多个队列。
Binding:绑定,它的作用就是把exchange和queue按照路由规则绑定起来.
Routing Key:路由关键字,exchange根据这个关键字进行消息投递。
vhost:虚拟主机,一个broker里可以有多个vhost,用作不同用户的权限分离。
Producer:消息生产者,就是投递消息的程序.
Consumer:消息消费者,就是接受消息的程序.
rabbitmq与redis对比
可靠消费
Redis:没有相应的机制保证消息的消费,当消费者消费失败的时候,消息体丢失,需要手动处理
RabbitMQ:具有消息消费确认,即使消费者消费失败,也会自动使消息体返回原队列,同时可全程持久化,保证消息体被正确消费
可靠发布
Reids:不提供,需自行实现
RabbitMQ:具有发布确认功能,保证消息被发布到服务器
高可用
Redis:采用主从模式,读写分离,但是故障转移还没有非常完善的官方解决方案
RabbitMQ:集群采用磁盘、内存节点,任意单点故障都不会影响整个队列的操作
持久化
Redis:将整个Redis实例持久化到磁盘
RabbitMQ:队列,消息,都可以选择是否持久化
消费者负载均衡
Redis:不提供,需自行实现
RabbitMQ:根据消费者情况,进行消息的均衡分发
队列监控
Redis:不提供,需自行实现
RabbitMQ:后台可以监控某个队列的所有信息,(内存,磁盘,消费者,生产者,速率等)
流量控制
Redis:不提供,需自行实现
RabbitMQ:服务器过载的情况,对生产者速率会进行限制,保证服务可靠性
出入队性能
对于RabbitMQ和Redis的入队和出队操作,各执行100万次,每10万次记录一次执行时间。
测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。
注:此数据来源于互联网,部分数据有误,已修正
应用场景分析
Redis:轻量级,高并发,延迟敏感
即时数据分析、秒杀计数器、缓存等
RabbitMQ:重量级,高并发,异步
批量数据异步处理、并行任务串行化,高负载任务的负载均衡等
https://www.cnblogs.com/peteremperor/p/10273077.html
rabbitmq和kafka的区别
rabbitmq每个broker只有一个master queue,所以吞吐量小
1、吞吐量
kafka吞吐量更高:
1)Zero Copy机制,内核copy数据直接copy到网络设备,不必经过内核到用户再到内核的copy,减小了copy次数和上下文切换次数,大大提高了效率。
2)磁盘顺序读写,减少了寻道等待的时间。
3)批量处理机制,服务端批量存储,客户端主动批量pull数据,消息处理效率高。
4)存储具有O(1)的复杂度,读物因为分区和segment,是O(log(n))的复杂度。
5)分区机制,有助于提高吞吐量。
2、可靠性
rabbitmq可靠性更好:
1)确认机制(生产者和exchange,消费者和队列);
2)支持事务,但会造成阻塞;
3)委托(添加回调来处理发送失败的消息)和备份交换器(将发送失败的消息存下来后面再处理)机制;
3、高可用
1)rabbitmq采用mirror queue,即主从模式,数据是异步同步的,当消息过来,主从全部写完后,回ack,这样保障了数据的一致性。
2)每个分区都可以有一个或多个副本,这些副本保存在不同的broker上,broker信息存储在zookeeper上,当broker不可用会重新选举leader。
kafka支持同步负责消息和异步同步消息(有丢消息的可能),生产者从zk获取leader信息,发消息给leader,follower从leader pull数据然后回ack给leader。
4、负责均衡
1)kafka通过zk和分区机制实现:zk记录broker信息,生产者可以获取到并通过策略完成负载均衡;通过分区,投递消息到不同分区,消费者通过服务组完成均衡消费。
2)需要外部支持。
5、模型
1)rabbitmq:
producer,broker遵循AMQP(exchange,bind,queue),consumer;
broker为中心,exchange分topic,direct,fanout和header,路由模式适合多种场景;
consumer消费位置由broker通过确认机制保存;
2)kafka:
producer,broker,consumer,未遵循AMQP;
consumer为中心,获取消息模式由consumer自己决定;
offset保存在消费者这边,broker无状态;
消息是名义上的永久存储,每个parttition按segment保存自己的消息为文件(可配置清理周期);
consumer可以通过重置offset消费历史消息;
需要绑定zk;
https://www.cnblogs.com/f-society/p/10731345.html
kafka分区选主机制
- Kafka中的分区器、序列化器、拦截器是否了解?它们之间的处理顺序是什么?
拦截器:interceptor使得用户在消息发送前以及producer回调逻辑前有机会对消息做一些定制化需求,比如修改消息等。同时,producer允许用户指定多个interceptor按序作用于同一条消息从而形成一个拦截链(interceptor chain)
序列化器:Producer发送消息要通过序列化器(Serializer)将消息对象转换成字节数组,才能通过网络传输到服务端,消费端则需要通过反序列化器(Deserializer)从服务端拉取字节数组转成消息对象
分区器:消息通过send方法发送过程中,可能会经过分区器(Partitioner)的作用才能发往broker端。如果消息ProducerRecord中指定了partition字段,那么就不需要分区器的作用,因为partition代表的就是所要发往的分区号。
消息缓冲池:生产端ProducerRecord经过序列化器、分区器处理后,并不是直接发往broker端,而是发送到客户端的消息缓冲池(Accumulator) 中,最后交由Sender线程发往broker端。
缓冲池最大大小由参数buffer.memory控制,默认是32M
https://zhuanlan.zhihu.com/p/136026887
https://blog.csdn.net/weixin_35720385/article/details/100745568
-
消费者重平衡(高可用性、伸缩性)
-
那些情景下会造成消息漏消费?
-
如何保证消息不被重复消费(幂等性)
-
KafkaConsumer是非线程安全的,那么怎么样实现多线程消费?
-
Kafka生产者客户端中使用了几个线程来处理?分别是什么?
-
消费者与生产者的工作流程:
-
topic的分区数可不可以增加?
celery
高并发降级
https://blog.csdn.net/qiaolong/article/details/73498050
与操作系统进程线程的区别
nginx
https://baijiahao.baidu.com/s?id=1652608869911988442&wfr=spider&for=pc
负载均衡
cookie session
redis
RDB与AOF:
https://baijiahao.baidu.com/s?id=1654694618189745916&wfr=spider&for=pc
ORM
Docker
分布式session设置
tornado处理请求流程
(1)生成application实例
(2)服务器监听
(3)到收到请求的时候,生成request对象,根据 交给 application查询路径映射表
(4)根据路径表生成handler实例.
(5)把request发送给handler实例.
(6)handler实例进行处理.
ioloop
https://blog.csdn.net/weixin_37947156/article/details/75324273
iostream
https://blog.csdn.net/joeyon1985/article/details/41956019?utm_source=blogxgwz2
https://www.cnblogs.com/MnCu8261/p/6703778.html ???
CAP
http://www.ruanyifeng.com/blog/2018/07/cap.html
mongodb cap
https://www.cnblogs.com/xybaby/p/6871764.html
keepalive解决nginx单点故障
https://blog.csdn.net/l1028386804/article/details/72801492
防止ip恶意访问
linux防火墙
nginx限制
python检测内存溢出
https://blog.csdn.net/kelindame/article/details/73008487