Skip to content

janlely/learning

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

50 Commits
readme.md
readme.md
 
 

Repository files navigation

高性能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抓包对性能的影响

网络编程相关

搜索相关

网络安全相关

大数据

设计模式

About

what to learn for a backend programer

Resources

Readme
Activity

Stars

2 stars

Watchers

1 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published