python后台知识点

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分区选主机制

2. 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

3. 消费者重平衡（高可用性、伸缩性）

4. 那些情景下会造成消息漏消费？

5. 如何保证消息不被重复消费（幂等性）

6. KafkaConsumer是非线程安全的，那么怎么样实现多线程消费？

7. Kafka生产者客户端中使用了几个线程来处理？分别是什么？

8. 消费者与生产者的工作流程：

9. 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