Skip to content

readme.md

Latest commit

 

History

History
424 lines (329 loc) · 18.6 KB

readme.md

File metadata and controls

424 lines (329 loc) · 18.6 KB

高性能IO

reactor

  • 最早一个线程用，阻塞，无法并发

  • 多线程，可并发，资源占用高，线程粒度大，要处理连接，读取和写入

  • reactor模式

  • 餐厅举例：

    • 多线程：一个服务员服务一个客人，点菜(读取)， 吃饭(处理)，埋单(写入)
    • reactor：一个服务员服务多个客人，事件驱动，当客人点菜的时候，服务员可以去服务其他客人，客人点完菜了，发送一个事件，叫来一个空闲的服务员。。。。

  • reactor需要依赖操作系统提供的selector系统调用(select, poll, epoll)

  • 参考资料1

  • 参考资料2

select，poll，epoll

  • select，poll，epoll都是IO多路复用的机制
  • select, poll缺点
    • 每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大
    • 同时每次调用select都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大
    • select支持的文件描述符数量太小了，默认是1024
  • epoll如何解决这些问题
    • fd只拷贝一次，在注册时拷贝
    • 为每个fd注册一个回调，事件发生时把对应的fd加入就绪列表
    • 数量为最大可打开的文件数
  • 参考资料

服务化

CS与BS架构区别

微服务(microservice)

负载均衡(load balance)

服务网格(Service Mesh)

无服务(serverLess)

服务间调用(RPC)

序列化

分布式事务

  • 原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)和持久性(Durabilily)，简称就是ACID
  • CAP定理: 一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance) 无法同时达到。
  • BASE理论：
    • Basically Available（基本可用）
    • Soft state（软状态）
    • Eventually consistent（最终一致性）
  • 两阶段提交（2PC）
    • 协调者、参与者
    • 协调者宕机会影响整个集群
    • 事务过程中所有参与者需要同步阻塞
    • 数据没有强一致，当协调者发出commit通知，而参与者未收到时会一直阻塞
  • 三阶段提交
    • 投票、预提交、提交
    • 超时机制
    • 没有强一致性
  • 补偿事务（TCC）
    • try, confirm, cancel
    • 数据一致性差，confirm和cancel都可能失败
  • 本地消息表（异步确保）
    • 业界使用最多(ebay)
    • 添加本地消息表
    • 消息和业务一起加入本地事务
    • 消息通过MQ发送给事务另一端(消费者)
    • 消费者通知生产者成功或失败(通过MQ或者直接远程调用)
    • 生产者定期扫描消息表，处理未完成的消息
  • MQ 事务消息
    • 类似两阶段提交的实现
    • 保证消息发送与本地事务同时成功或同时失败
    • RocketMQ支持事务消息
    • 主流的MQ不支持，RabbitMQ, kafka
  • Sagas 事务模型（略）
  • 参考资料

分布式数据一致性

TLA+

jvm工具

高可用

阿里巴巴高可用架构的演进史

双活数据中心架构分析及优缺点

PXC的原理

带你玩转Mysql高可用方案--PXC

分布式、多活数据中心如何实现DNS域名解析和负载均衡？

数据存储

关系型

  • mysql
  • postgresql

KV型

  • redis

乐观锁、悲观锁

  • 乐观锁: 认为并发不会带来问题，一开始不拿锁，允许并发，如果失败了再重试或者回滚

    • CAS(Compare and Swap 比较并交换), 更新前先比较
    • 表中添加version字段，更新时判断version字段是否和之前取到的一致，不一致则重试或回滚
    select version, data from t_table;
update t_table set data = #{data}, version = version + 1 where version = #{version};
    • 如果经常失败则性能差

  • 悲观锁: 认为并发会带来问题，一开始就拿锁，不允许并发

数据库索引实现方式

Mysql索引实现 MySQL的InnoDB索引原理详解

  • AVL-Tree, B-Tree, B+Tree
    • AVL：平衡二叉树
  • MyISAM
    • B+Tree
    • 叶节点的data域存数据记录的地址
    • 可以没有主键
    • 索引文件和数据文件分开存储
  • InnoDB
    • B+Tree
    • 必须有主键，如果没指定会有隐藏主键
    • 数据按主键聚集
    • 主键叶子节点保存了数据本身
    • 主键索引十分高效
    • 辅助索引的data域是主键
    • 索引文件包含了数据

mysql事务、并发、锁机制

  • 这篇文章讲得很详细
  • 行级锁、表级锁、页级锁
    • 表级锁: 锁定整个表(MyISAM)，加锁快、易冲突、低并发
    • 页级锁: 锁定一个数据块(BDB)
    • 行级锁: 锁定索引到的行(InnoDB)，加锁慢、不易冲突、高并发
  • InnoBD中的两种行级锁:
    • 共享锁: ...lock in share mode 允许一个事务去读，阻止其他事务获得相同数据集的排他锁。什么意思：
      • 可以读
      • 不能加排他锁
    • 排他锁: ...for update 允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。什么意思：
      • 可以读
      • 不能加共享锁
  • InnoDB事务执行流程

MYSQL其他

视图

主从原理

秒杀系统设计方法

HTTP2

消息队列

rabbitMQ

  • AMQP协议
  • Exchanges: 接收生产者发送的消息
    • Exchanges三种模式详解
    • Direct: Queue需要bind到Exchange上并要求一个routing key，完全匹配routing key的消息会转发到Queue。
    • 消息发送到与Exchange bind的所有Queue上
    • Topic: 和Direct的区别是，routing key采用模式匹配
  • Queue: 生产者发的消息最终达到这里
  • Bindings: 决定消息如何路由到正确的Queue
  • Routing key: 消息路由到Queue时的关键词
  • Ack: 消息确认，默认为自动确认，server端不必等待consumer端确认，就丢弃消息。开启手动确认后，server端等待consumer确认之后才会丢弃消息。如果consumer未发送ack,则server通过consumer的连接是中断来确认消息是否可以重新发给的其他的consumer。
  • 事务和Confirm: 为了解决broker到publisher的确认，默认不开启。

Ack and Confirm

kafka

redis

容器技术

函数式编程(FP)

VOIP与通信相关

SIP

FREESWITCH

语音业务VOIP开发之SIP协议篇：SIP报文浅析

SIPXECS

sipxecs总体介绍

OPENSIPS

opensips介绍

Asterisk

开源软交换系统 FreeSwitch 与 Asterisk 比较

FREESWITCH应用优化

IMS网络相关

计算机网络相关

NAT相关

NAT穿越 单IP做NAT支持的最大连接数问题

HTTP相关

跨域

跨域资源共享 CORS 详解

C编译相关

configure, make, make install

加密相关

前后端分享API文档生成工具

nodejs 工具

网络抓包相关

tcpdump抓包对性能的影响

网络编程相关

搜索相关

网络安全相关

大数据

设计模式