- 博客(321)
- 资源 (6)
- 收藏
- 关注
RSS订阅翻译 HTTP系列八、HTTP的Cookie机制
HTTP 里“无状态”的特性，服务器是不能感知客户端状态信息，那么可以通过HTTP 的 Cookie 机制，服务器给每个客户端都贴上一张小纸条，上面写了一些只有服务器才能理解的数据，需要的时候客户端把这些信息发给服务器，服务器看到 Cookie，就能够认出对方是谁了。
2023-06-10 23:01:37
1319
翻译 HTTP系列七、HTTP的连接管理
而在长连接的情况下，同样发送三次请求，因为只在第一次时建立连接，在最后一次时关闭连接，所以浪费率就是“3÷9≈33%”，降低了差不多一半的时间损耗。不需要用什么特殊的头字段指定，只要向服务器发送了第一次请求，后续的请求都会重复利用第一次打开的 TCP 连接，也就是长连接，在这个连接上收发数据。继续用刚才的打卡机的比喻，公司也觉得这种反复“开盖 - 打卡 - 关盖”的操作太“反人类”了，于是颁布了新规定，早上打开盖子后就不用关上了，可以自由打卡，到下班后再关上盖子。这种方式也存在缺陷。
2023-06-10 22:45:22
335
翻译 HTTP系列六、HTTP传输大文件
早期互联网上传输的基本上都是只有几 K 大小的文本和小图片，现在的情况则大有不同。网页里包含的信息实在是太多了，随随便便一个主页 HTML 就有可能上百 K，高质量的图片都以 M 论，更不要说那些电影、电视剧了，几 G、几十 G 都有可能。如何在有限的带宽下高效快捷地传输这些大文件就成了一个重要的课题。
2023-06-10 20:43:31
1032
翻译 HTTP系列五、HTTP的Body体的内容协商
常见的有 application/json，application/javascript、application/pdf 等，另外，如果实在是不知道数据是什么类型，像刚才说的“黑盒”，就会是 application/octet-stream，即不透明的二进制数据。但仅有 MIME type 还不够，因为 HTTP 在传输时为了节约带宽，有时候还会压缩数据，为了不要让浏览器继续“猜”，还需要有一个“Encoding type”，告诉数据是用的什么编码格式，这样对方才能正确解压缩，还原出原始的数据。
2023-06-10 19:54:43
932
翻译 HTTP系列四、HTTP1.1特点
但在虚拟的网络世界里这却是个麻烦事。例如电商购物，首先要登录，然后添加购物车，再下单、结算、支付，这一系列操作都需要知道用户的身份才行，但“无状态”服务器是不知道这些请求是相互关联的，每次都得问一遍身份信息，不仅麻烦，而且还增加了不必要的数据传输量。随着互联网特别是移动互联网的普及，HTTP 的触角已经延伸到了世界的每一个角落：从简单的 Web 页面到复杂的 JSON、XML 数据，从台式机上的浏览器到手机上的各种 APP，从看新闻、泡论坛到购物、理财、“吃鸡”，你很难找到一个没有使用 HTTP 的地方。
2023-06-10 19:24:29
2224
翻译 HTTP系列三、HTTP报文和请求
HTTP 协议在规范文档里详细定义了报文的格式，规定了组成部分，解析规则，还有处理策略，所以可以在 TCP/IP 层之上实现更灵活丰富的功能，例如连接控制，缓存管理、数据编码、内容协商等等。
2023-04-16 16:53:08
857
翻译 HTTP系列一、HTTP的前世今生
在 HTTP/2 还处于草案之时，Google 又发明了一个新的协议，叫做 QUIC，而且还是相同的“套路”，继续在 Chrome 和自家服务器里试验着“玩”，依托它的庞大用户量和数据量，持续地推动 QUIC 协议成为互联网上的“既成事实”。Google 首先开发了自己的浏览器 Chrome，然后推出了新的 SPDY 协议，并在 Chrome 里应用于自家的服务器，如同十多年前的网景与微软一样，从实际的用户方来“倒逼”HTTP 协议的变革，这也开启了第二次的“浏览器大战”。这篇论文中他确立了三项关键技术。
2023-04-16 14:35:28
159
翻译 RPC系列九、提升单机吞吐量
当收到服务端响应的消息时，调用端会根据响应消息的唯一标识，通过之前存储的映射找到对应的 Future，将结果注入给那个 Future，再进行一系列的处理逻辑，最后动态代理从 Future 中获得到正确的返回值。当然不会在一个，对二进制消息数据包拆解包的处理是一定要在处理网络 IO 的线程中，如果网络通信框架使用的是 Netty 框架，那么对二进制包的处理是在 IO 线程中，而解码与反序列化的过程也往往在 IO 线程中处理，那服务端的业务逻辑呢？这样一来的话，业务逻辑执行完的时间在理想的情况下是多少毫秒呢？
2023-04-15 17:00:23
256
翻译 RPC系列八、隔离流量
那说起突发流量，限流固然是一种手段，但其实面对复杂的业务以及高并发场景时，我们还有别的手段，可以最大限度地保障业务无损，那就是隔离流量。这也是今天重点分享的内容，接下来一起看看分组在 RPC 中的应用。
2023-04-15 16:04:28
194
翻译 RPC系列七、熔断和限流
RPC 是解决分布式系统通信问题的一大利器，而分布式系统的一大特点就是高并发，所以说 RPC 也会面临高并发的场景。在这样的情况下，我们提供服务的每个服务节点就都可能由于访问量过大而引起一系列的问题，比如业务处理耗时过长、CPU 飘高、频繁 Full GC 以及服务进程直接宕机等等。但是在生产环境中，我们要保证服务的稳定性和高可用性，这时我们就需要业务进行自我保护，从而保证在高访问量、高并发的场景下，应用系统依然稳定，服务依然高可用。
2023-04-08 21:44:18
294
翻译 RPC系列六、RPC服务的优雅启动和关闭
RPC 体系里，要考虑，在重启服务的过程中，RPC 怎么做到让调用方系统不出问题呢？要想说明白这事，先要简述下上线的大概流程：当服务提供方要上线的时候，一般是通过部署系统完成实例重启。在这个过程中，服务提供方的团队并不会事先告诉调用方他们需要操作哪些机器，从而让调用方去事先切走流量。而对调用方来说，它也无法预测到服务提供方要对哪些机器重启上线，因此负载均衡就有可能把要正在重启的机器选出来，这样就会导致把请求发送到正在重启中的机器里面，从而导致调用方不能拿到正确的响应结果。
2023-04-08 21:18:25
1305
翻译 RPC系列四、负载均衡
这里我们可以采用一种打分的策略，服务调用者收集与之建立长连接的每个服务节点的指标数据，如服务节点的负载指标、CPU 核数、内存大小、请求处理的耗时指标（如请求平均耗时、TP99、TP999）、服务节点的状态指标（如正常、亚健康）。RPC 的负载均衡完全由 RPC 框架自身实现，RPC 的服务调用者会与“注册中心”下发的所有服务节点建立长连接，在每次发起 RPC 调用时，服务调用者都会通过配置的负载均衡插件，自主选择一个服务节点，发起 RPC 调用请求。通过硬件设备来实现的负载均衡，如 F5 服务器等。
2023-04-08 19:01:33
302
翻译 RPC系列三、路由策略
在真实环境中我们的服务提供方是以一个集群的方式提供服务，这对于服务调用方来说，就是一个接口会有多个服务提供方同时提供服务，所以我们的 RPC 在每次发起请求的时候，都需要从多个服务提供方节点里面选择一个用于发请求的节点。既然服务提供方是以集群的方式对外提供服务，每次上线应用的时候都不止一台服务器会运行实例，那上线就涉及到变更，只要变更就可能导致原本正常运行的程序出现异常，尤其是发生重大变动的时候，导致我们应用不稳定的因素就变得很多。
2023-04-08 17:38:30
184
翻译 RPC系列三、健康检测
调用方跟服务集群节点之间的网络状况是瞬息万变的，两者之间可能会出现闪断或者网络设备损坏等情况，那怎么保证选择出来的连接一定是可用的呢？终极的解决方案是让调用方实时感知到节点的状态变化这样调用方才能做出正确的选择。这个道理像我们开车一样，车有各种各样的零件，我们不可能在开车之前先去挨个检查下他们的健康情况，转而是应该有一套反馈机制。那回到 RPC 框架里，应该怎么设计这套机制呢？你可以先停下来想想汽车的例子，看看他们是怎么做的。当然，回到我们 RPC 的框架里，这事用专业一点的词来说就是服务的健康检测。
2023-04-08 17:22:06
285
翻译 RPC系列二、服务发现
引发这次问题的根本原因就是 ZooKeeper 本身的性能问题，当连接到 ZooKeeper 的节点数量特别多，对 ZooKeeper 读写特别频繁，且 ZooKeeper 存储的目录达到一定数量的时候，ZooKeeper 将不再稳定，CPU 持续升高，最终宕机。（3）当服务调用方发起订阅时，则在服务调用方目录中创建一个临时节点，节点中存储该服务调用方的信息，同时服务调用方 watch 该服务的服务提供方目录（/service/com.demo.xxService/provider）中所有的服务节点数据。
2023-04-08 16:54:16
473
翻译 RPC系列一、设计一个灵活的RPC框架
在实际的网络传输过程中，请求数据包在数据链路层可能会因为太大而被拆分成多个数据包进行传输，为了减少被拆分的次数，从而导致整个传输过程时间太长的问题，可以在 RPC 调用的时候这样操作：在方法调用参数或者返回值的二进制数据大于某个阈值的情况下，可以通过压缩框架进行无损压缩，然后在另外一端也用同样的压缩算法进行解压，保证数据可还原。说它是静态数据是因为，对于RPC 来说，每次发送请求的时候都是需要用 TCP 连接的，相对服务提供方 IP 地址，TCP 连接状态是瞬息万变的，所以 RPC 框架里面要有。
2023-04-08 16:21:00
468
翻译 缓冲池（buffer pool）详解
InnoDB存储引擎是以页为单位来管理空间的，我们进行的增删改查操作其实本质都是在访问页面（读页面，写页面，创建新页面）等，磁盘IO需要消耗的时间很多，而在内存中进行操作，效率会高，为了能让数据表或者索引中的数据随时被使用，DBMS会申请占用内存来作为数据缓冲池，在真正访问页面之前，需要把磁盘上的页缓存到内存中的buffer pool中之后才可以访问。这样做的好处可以让磁盘活动量最小，从而减少与磁盘直接进行IO，这种策略可以提升SQL语句的查询性能。如果索引的数据在缓冲池中，那么访问的成本就会降低很多。
2023-04-01 18:33:22
3478
1
翻译 SQL执行流程详解
既然是缓存，缓存失效也要考虑，MYSQL的缓存系统会检测涉及到的每张表，只要该表的结构或者数据被修改，出现如下操作（insert，update，delete，truncat table，alter table，drop table，drop database等）时所有缓存查询将变为无效，对于更新压力大的数据库来说，查询缓存命中率更低。key是查询语句，value是查询的结果，如果查询能够直接在缓存中找到key，那么这个value就会被直接返回给客户端，如果语句不在查询缓存中，就会继续后面的执行阶段。
2023-04-01 16:33:05
2339
翻译 Calcite文档翻译-概览
一、背景Apache Calcite 是一个动态数据管理框架，它包含构成典型数据库管理系统的许多部分，但省略了一些关键功能：数据存储、处理数据的算法和用于存储元数据的存储库。Calcite 有意远离存储和处理数据的业务。这使其成为在应用程序与一个或多个数据存储位置和数据处理引擎之间进行调解的绝佳选择。它也是构建数据库的完美基础：只需添加数据即可。为了说明这一点，让我们创建一个空的Calcite实例，然后将其指向一些数据。public class Demo1 { public st
2023-03-15 00:09:28
233
翻译 主从复制一之概述
大部分应用对数据库而言都是“ 读多写少 ”，也就说对数据库读取数据的压力比较大，有一个思路就是采用数据库集群的方案，做 主从架构 、进行 读写分离 ，这样同样可以提升数据库的并发处理能力。但并不是所有的应用都需要对数据库进行主从架构的设置，毕竟设置架构本身是有成本的。如果目的在于提升数据库高并发访问的效率，那么首先考虑的是如何 优化SQL和索引 ，这种方式简单有效；其次才是采用 缓存的策略 ，比如使用 Redis将热点数据保存在内存数据库中，提升读取的效率；最后才是对数据库采用 主从架构 ，进行读
2022-05-15 22:20:18
686
翻译 日志系列二之二进制日志原理篇
一、写入机制binlog的写入时机也非常简单，事务执行过程中，先把日志写到 binlog cache ，事务提交的时候，再把binlog cache写到binlog文件中。因为一个事务的binlog不能被拆开，无论这个事务多大，也要确保一次性写入，所以系统会给每个线程分配一个块内存作为binlog cache。可以通过binlog_cache_size参数控制单个线程binlog cache大小，如果存储内容超过了这个参数，如果存储内容超过这个参数，会存储到磁盘中。write和fsync的时
2022-05-08 22:19:28
399
翻译 静态资源配置原理
SpringMVC功能的自动配置类 WebMvcAutoConfiguration一、WebMvcAutoConfiguration@Configuration(proxyBeanMethods = false)@ConditionalOnWebApplication(type = Type.SERVLET)@ConditionalOnClass({ Servlet.class, DispatcherServlet.class, WebMvcConfigurer.class })@Cond
2022-05-08 19:02:30
126
翻译 日志系列一之通用查询日志(general query log)
一、通用查询日志用来记录用户的所有操作 ，包括启动和关闭MySQL服务、所有用户的连接开始时间和截止时间、发给 MySQL 数据库服务器的所有 SQL 指令等。当我们的数据发生异常时，查看通用查询日志，还原操作时的具体场景，可以帮助我们准确定位问题。问题场景在电商系统中，购买商品并且使用微信支付完成后，却发现支付中心的记录并没有新增，此时用户再次使用支付宝支付，就会出现重复支付的问题。但是当天去数据库中查询数据的时候，就会发现只有一条记录存在，那么此时给到的现象就是只有一条支付记录，但是用户却支
2022-05-01 12:23:11
823
翻译 多版本并发控制（MVCC）
一、MVCCMVCC （Multiversion Concurrency Control），多版本并发控制。顾名思义，MVCC 是通过数据行的多个版本管理来实现数据库的 并发控制 。这项技术使得在InnoDB的事务隔离级别下执行 一致性读 操作有了保证。换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另一个事务释放锁。二、 快照读与当前读MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理 读-写
2022-04-30 21:10:35
4291
2
翻译 锁系列五之锁内存结构和锁监控
前面文章说对一条记录加锁的本质是在内存中创建一个锁结构与之关联，那么是不是一个事务对多条记录加锁，就要创建多个锁结构？比如下面的sqlselect * from user lock in share mode理论上创建多个锁结构没问题，但是如果一个事务获取10000条记录的锁，生成10000个锁结构也太浪费了。所以决定在对不同记录加锁时，如果符合下面的条件的记录会放到一个锁结构中。（1）在同一个事务中进行加锁操作（2）被加锁的记录在同一个页中（3）加锁的类型是一样的（4）等待状态
2022-04-23 21:58:11
377
翻译 锁系列四之行锁
行锁，也称为记录锁，mysql服务层没有实现行锁机制，行锁只存在存储引擎层实现。优点：锁粒度小，发生锁冲突的概率低，可以实现的并发度高。缺点：对于锁的开销比较大，加锁会比较慢，容易出现死锁的情况。案例一、记录锁（Record Locks）记录锁也就是仅仅把一条记录锁上，Lock_REC_NOT_GAP，比如把id=8的记录加上一个记录锁的示意图如下。记录锁是有S锁和X锁之分的，称之为 S型记录锁 和 X型记录锁（1）当一个事务获取了一条记录的S型记录锁后，其他事务也可..
2022-04-09 16:32:57
5092
翻译 事务系列三事务日志
事务有4种特性：原子性、一致性、隔离性和持久性。事务的隔离性由 锁机制 实现。事务的原子性、一致性和持久性由事务的 redo 日志和undo 日志来保证。（1）REDO LOG 称为 重做日志 ，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性。redo log是存储引擎(innodb)生成的日志，记录的是物理级别上的页修改操作。比如页号xxx，偏移量yyy写入了zzz数据，主要为了保证数据的可靠性。（2）UNDO LOG 称为 回滚日志 ，回滚行记录到某个特定版本，用来保证事
2022-03-13 16:09:34
1546
翻译 事务系列二隔离级别
MySQL是一个 客户端／服务器 架构的软件，对于同一个服务器来说，可以有若干个客户端与之连接，每个客户端与服务器连接上之后，就可以称为一个会话（ Session ）。每个客户端都可以在自己的会话中向服务器发出请求语句，一个请求语句可能是某个事务的一部分，也就是对于服务器来说可能同时处理多个事务。事务有 隔离性 的特性，理论上在某个事务 对某个数据进行访问 时，其他事务应该进行 排队 ，当该事务提交之后，其他事务才可以继续访问这个数据。但是这样对 性能影响太大 ，我们既想保持事务的隔离性，又想让服务器在处理
2022-03-13 09:23:13
372
翻译 事务系列一事务基础概述
事务定义一组逻辑操作单元，使数据从一种状态变换到另一种状态一、存储引擎支持情况二、事务的ACID特性1、原子性（atomicity）原子性是指事务是一个不可分割的工作单位，要么全部提交，要么全部失败回滚。2、一致性（consistency）一致性是指事务执行前后，数据从一个合法性状态变换到另外一个合法性状态 。这种状态是语义上的而不是语法上的，跟具体的业务有关。通俗的说，这种状态是由自己定义的（比如要满足现实世界中的约束），满足这个状态，数据就是一致的，不满足这个状态，数据
2022-03-10 00:31:56
348
翻译 DataX源码解析
一、总体流程1、黄色Job 部分的执行阶段2、蓝色Task 部分的执行阶段3、绿色框架执行阶段二、程序入口1、查看datax.pyENGINE_COMMAND = "java -server ${jvm} %s -classpath %s ${params}com.alibaba.datax.core.Engine -mode ${mode} -jobid ${jobid} -job ${job}" % (DEFAULT_PROPERTY_CONF, CLASS_
2022-02-12 19:43:53
718
翻译 锁系列三之表锁
表锁（Table Lock）是mysql中最基本的锁策略，并不依赖存储引擎，表锁是开销最小的策略（因为粒度比较大）。由于表锁是锁住整张表，所以可以避免死锁。不过最大的负面问题是锁竞争概率最高。并发性最差。1、表级别的S锁、X锁在对某个表执行SELECT、INSERT、DELETE、UPDATE语句时，InnoDB存储引擎是不会为这个表添加表级别的 S锁 或者 X锁 的。在对某个表执行一些诸如 ALTER TABLE 、 DROP TABLE 这类的 DDL 语句时，其他事务对这个表并发执行...
2022-01-19 01:02:35
2128
翻译 锁系列二之读写锁
从数据操作的类型划分对于 InnoDB 引擎来说，读锁和写锁可以加在表上，也可以加在行上。一、读锁也称为 共享锁 、英文用 S 表示。针对同一份数据，多个事务的读操作可以同时进行而不会互相影响，相互不阻塞的。二、写锁也称为 排他锁 、英文用 X 表示。当前写操作没有完成前，它会阻断其他写锁和读锁。这样就能确保在给定的时间里，只有一个事务能执行写入，并防止其他用户读取正在写入的同一资源。1、锁定读在采用加锁方式解决脏读，不可重复读，幻读这些问题的时候，读取一条记录时需要获取该记..
2022-01-19 00:52:54
1172
翻译 锁系列一之概述
一、MySQL并发事务访问相同记录1、读-读情况读-读 情况，即并发事务相继 读取相同的记录 。读取操作本身不会对记录有任何影响，并不会引起什么问题，所以允许这种情况的发生。2、写-写情况即并发事务相继对相同的记录做出改动在这种情况下会发生 脏写 的问题，任何一种隔离级别都不允许这种问题的发生。所以在多个未提交事务相继对一条记录做改动时，需要让它们 排队执行 ，这个排队的过程其实是通过 锁 来实现的。这个所谓的锁其实是一个 内存中的结构 ，在事务执行前本来是没有锁的，也就是说一开始是没有
2022-01-19 00:52:31
160
翻译 hbase体系结构
hbase是master-slave模型一、client（客户端）1、shell命令行接口2、原生java api接口3、thrift/rest api接口4、mapreduce接口用于批量数据导入和读取二、zookeeper1、实现master高可用2、管理系统核心元数据3、参与regionserver宕机恢复4、实现分布式表锁三、master1、处理用户的各种管理请求建表，修改表，权限操作，切分表，合并数据分片，以及compaction等2
2022-01-05 01:10:22
394
翻译 hbase数据模型
hbase是一个类似于Map，由键值对构成，是一个稀疏，分布式，多维排序的map。一、逻辑视图1、table（表）包含多条数据2、row（行）一行数据包含唯一标识(rowkey)，多个column以及对应的值，一张表中的所有row都是按照rowkey的字典序由小到大排序3、column（列）由column family（列簇）和qualifier（列名）两部分构成。格式为column family:qualifiercolumn family不能随意更改，但是column f
2022-01-05 00:31:08
669
翻译 并发设计模式系列一 同步模式之保护性暂停
保护性暂停，用在一个线程等待另一个线程的执行结果。JDK 中，join 的实现、Future 的实现，采用的就是此模式。class GuardedObject{ private final Object lock=new Object(); private Object response; public Object get() throws Exception{ synchronized (lock){ while (res.
2021-12-12 15:38:33
126
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人