用户5623390688075
获得徽章 0
http1.1中浏览器再也不用为每个请求重新发起TCP连接了，增加内容有：缓存相关首部的扩展，OPTIONS方法，Upgrade首部，Range请求，压缩和传输编码，管道化等。但还是满足不了现在的web发展需求，so，就有了http.2版本。
http2解决了（管道化特性可以让客户端一次发送所有的请求，但是有些问题阻碍了管道化的发展，即是某个请求花了很长时间，那么队头阻塞会影响其他请求。）http中的队头阻塞问题。
使用http2会比http1.1在使用TCP时，用户体验的感知多数延迟的效果有了量化的改善，以及提升了TCP连接的利用率（并行的实现机制不依赖与服务器建立多个连接）
所以需要学习http2，了解更过的内容来掌握计算机网咯。
对于http2，你可以来运行一个http2的服务器，获取并安装一个http2的web服务器，下载并安装一张TLS证书，让浏览器和服务器通过http2来连接。（从数字证书认证机构申请一张证书）。
了解http2的协议，先让我们了解一下web页面的请求，就是用户在浏览器中呈现的效果，发生了些什么呢？
http2解决了（管道化特性可以让客户端一次发送所有的请求，但是有些问题阻碍了管道化的发展，即是某个请求花了很长时间，那么队头阻塞会影响其他请求。）http中的队头阻塞问题。
使用http2会比http1.1在使用TCP时，用户体验的感知多数延迟的效果有了量化的改善，以及提升了TCP连接的利用率（并行的实现机制不依赖与服务器建立多个连接）
所以需要学习http2，了解更过的内容来掌握计算机网咯。
对于http2，你可以来运行一个http2的服务器，获取并安装一个http2的web服务器，下载并安装一张TLS证书，让浏览器和服务器通过http2来连接。（从数字证书认证机构申请一张证书）。
了解http2的协议，先让我们了解一下web页面的请求，就是用户在浏览器中呈现的效果，发生了些什么呢？
展开
评论
点赞
#挑战每日一条沸点# 然而，在创建时，这个对象不再是空的。尽管 hashMap 是用一个空的对象字面量创建的，但它自动继承了 Object.prototype。这就是为什么我们可以在 hashMap 上调用hasOwnProperty、toString、constructor 等方法，尽管我们从未在该对象上明确定义这些方法。
由于原型继承，我们现在有两种类型的属性被混淆了：存在于对象本身的属性，即它自己的属性，以及存在于原型链的属性，即继承的属性。
因此，我们需要一个额外的检查（例如hasOwnProperty）来确保一个给定的属性确实是用户提供的，而不是从原型继承的。
除此之外，由于属性解析机制在 JavaScrip t中的工作方式，在运行时对 Object.prototype 的任何改变都会在所有对象中引起连锁反应。这就为原型污染攻击打开了大门，这对大型的JavaScript 应用程序来说是一个严重的安全问题。
不过，我们可以通过使用 Object.create(null) 来解决这个问题，它可以生成一个不继承Object.prototype的对象。
由于原型继承，我们现在有两种类型的属性被混淆了：存在于对象本身的属性，即它自己的属性，以及存在于原型链的属性，即继承的属性。
因此，我们需要一个额外的检查（例如hasOwnProperty）来确保一个给定的属性确实是用户提供的，而不是从原型继承的。
除此之外，由于属性解析机制在 JavaScrip t中的工作方式，在运行时对 Object.prototype 的任何改变都会在所有对象中引起连锁反应。这就为原型污染攻击打开了大门，这对大型的JavaScript 应用程序来说是一个严重的安全问题。
不过，我们可以通过使用 Object.create(null) 来解决这个问题，它可以生成一个不继承Object.prototype的对象。
展开
评论
点赞
#青训营笔记创作活动# 规范制定
从 0 到 1，从无到有，这个环节应该有 Leader 或架构师，充分考虑公司实际情况，参考行业标准或约定俗成的规范，综合统一制定。
也可以将规范拆分后交由各个部分核心开发人员编写， Leader 或架构师统一整合。比如我们之前的团队就是，模型设计师负责模型设计规范，ETL 工程师负责 ETL 开发规范，BI 开发人员制定前端开发规范，部署上线规范直接采用项目上已有的即可。
总体上，初稿应该尽量保证规范的完整性和各个部分间的兼容性。
qin
从 0 到 1，从无到有，这个环节应该有 Leader 或架构师，充分考虑公司实际情况，参考行业标准或约定俗成的规范，综合统一制定。
也可以将规范拆分后交由各个部分核心开发人员编写， Leader 或架构师统一整合。比如我们之前的团队就是，模型设计师负责模型设计规范，ETL 工程师负责 ETL 开发规范，BI 开发人员制定前端开发规范，部署上线规范直接采用项目上已有的即可。
总体上，初稿应该尽量保证规范的完整性和各个部分间的兼容性。
qin
展开
评论
点赞
#青训营笔记创作活动# 用 Redis 做缓存，并不是一说缓存就是 Redis，还是要结合业务的具体情况，我们可以根据不同业务对数据要求的实时性不同，将数据分为三级，以电商项目为例：
第 1 级：订单数据和支付流水数据：这两块数据对实时性和精确性要求很高，所以一般是不需要添加缓存的，直接操作数据库即可。
第 2 级：用户相关数据：这些数据和用户相关，具有读多写少的特征，所以我们使用 redis 进行缓存。
第 3 级：支付配置信息：这些数据和用户无关，具有数据量小，频繁读，几乎不修改的特征，所以我们使用本地内存进行缓存。
选中合适的数据存入 Redis 之后，接下来，每当要读取数据的时候，就先去 Redis 中看看有没有，如果有就直接返回；如果没有，则去数据库中读取，并且将从数据库中读取到的数据缓存到 Redis 中，大致上就是这样一个流程，读取数据的这个流程实际上是比较清晰也比较简单的，没啥好说的。
然而，当数据存入缓存之后，如果需要更新的话，往往会来带另外的问题：
当有数据需要更新的时候，先更新缓存还是先更新数据库？如何确保更新缓存和更新数据库这两个操作的原子性？
更新缓存的时候该怎么更新？修改还是删除？
怎么办？正常来说，我们有四种方案：
先更新缓存，再更新数据库。
先更新数据库，再更新缓存。
先淘汰缓存，再更新数据库。
先更新数据库，再淘汰缓存。
到底使用哪种？
在回答这个问题之前，我们不妨先来看看三个经典的缓存模式：
Cache-Aside
Read-Through/Write through
Write Behind
2. Cache-Aside
Cache-Aside，中文也叫旁路缓存模式，如果我们能够在项目中采用 Cache-Aside，那么就能够尽可能的解决缓存与数据库数据不一致的问题，注意是尽可能的解决，并无法做到绝对解决
第 1 级：订单数据和支付流水数据：这两块数据对实时性和精确性要求很高，所以一般是不需要添加缓存的，直接操作数据库即可。
第 2 级：用户相关数据：这些数据和用户相关，具有读多写少的特征，所以我们使用 redis 进行缓存。
第 3 级：支付配置信息：这些数据和用户无关，具有数据量小，频繁读，几乎不修改的特征，所以我们使用本地内存进行缓存。
选中合适的数据存入 Redis 之后，接下来，每当要读取数据的时候，就先去 Redis 中看看有没有，如果有就直接返回；如果没有，则去数据库中读取，并且将从数据库中读取到的数据缓存到 Redis 中，大致上就是这样一个流程，读取数据的这个流程实际上是比较清晰也比较简单的，没啥好说的。
然而，当数据存入缓存之后，如果需要更新的话，往往会来带另外的问题：
当有数据需要更新的时候，先更新缓存还是先更新数据库？如何确保更新缓存和更新数据库这两个操作的原子性？
更新缓存的时候该怎么更新？修改还是删除？
怎么办？正常来说，我们有四种方案：
先更新缓存，再更新数据库。
先更新数据库，再更新缓存。
先淘汰缓存，再更新数据库。
先更新数据库，再淘汰缓存。
到底使用哪种？
在回答这个问题之前，我们不妨先来看看三个经典的缓存模式：
Cache-Aside
Read-Through/Write through
Write Behind
2. Cache-Aside
Cache-Aside，中文也叫旁路缓存模式，如果我们能够在项目中采用 Cache-Aside，那么就能够尽可能的解决缓存与数据库数据不一致的问题，注意是尽可能的解决，并无法做到绝对解决
展开
评论
点赞
我们网络传输协议最底层是 SSL/TLS，蚂蚁是基于 TLS1.3 自研了 MTLS，上一层是会话层，最开始基于 HTTP，现在基于自研的通信协议 MMTP，最上层是 RPC、SYNC、PUSH 应用层协议。
RPC 解决“请求 - 响应”的通信模式；SYNC 负责“服务器直接推送数据到客户端”的通信模式；PUSH 负责“推传统的 PUSH 弹框通知”。
另外我们还重新定义了 HTTP2，引入 H2+ 私有帧协议，支持了自定义双向通信，HTTP2 现在基本上已经定为下一代通信协议，主流的浏览器都已经支持了。同时我们也引进到移动端，因为它具有多路复用、hpack 高可压缩算法等很多对移动网络友好的特性。
接下来我们讲一下 SYNC 机制。
本质上 SYNC 是基于 SyncKey 的一种同步协议。我们直接举个“账单页展示”的例子来解释什么是 SYNC：传统意义上客户端要拉取这个人所有的账单，就发 RPC 请求给服务器，服务器把所有的数据一下子拉回来，很耗费流量。我们的 SYNC 机制是同步差量数据，这样达到了节省流量的效果，数据量小了通信效率也更高效，客户端拿到服务端数据的成功率更高。
另外对于 SYNC 机制，客户端还无需实时在线，对于用户不在线的情况，SYNC Server 会将差量数据保存在数据库中。当客户端下次连接到服务器时，再同步差量数据给用户。在支付宝内部，我们在聊天、配置同步、数据推送等场景都应用了 SYNC 机制。
RPC 解决“请求 - 响应”的通信模式；SYNC 负责“服务器直接推送数据到客户端”的通信模式；PUSH 负责“推传统的 PUSH 弹框通知”。
另外我们还重新定义了 HTTP2，引入 H2+ 私有帧协议，支持了自定义双向通信，HTTP2 现在基本上已经定为下一代通信协议，主流的浏览器都已经支持了。同时我们也引进到移动端，因为它具有多路复用、hpack 高可压缩算法等很多对移动网络友好的特性。
接下来我们讲一下 SYNC 机制。
本质上 SYNC 是基于 SyncKey 的一种同步协议。我们直接举个“账单页展示”的例子来解释什么是 SYNC：传统意义上客户端要拉取这个人所有的账单，就发 RPC 请求给服务器，服务器把所有的数据一下子拉回来，很耗费流量。我们的 SYNC 机制是同步差量数据，这样达到了节省流量的效果，数据量小了通信效率也更高效，客户端拿到服务端数据的成功率更高。
另外对于 SYNC 机制，客户端还无需实时在线，对于用户不在线的情况，SYNC Server 会将差量数据保存在数据库中。当客户端下次连接到服务器时，再同步差量数据给用户。在支付宝内部，我们在聊天、配置同步、数据推送等场景都应用了 SYNC 机制。
展开
评论
点赞
支付宝移动网络第四代架构
关于第四代支付宝移动架构演进，我们主要做了两件事情：第一，统一网络库；第二，网关去中心化。
一方面，客户端平台需要覆盖 iOS、Android，此外还有 IOT RTOS 等平台，未来还需要支持更多端。然而每支持一个平台，我们都需要重新开发一套网络库；另一方面，我们的客户端网络库有比较丰富且复杂的策略，我们经常会发现，每个平台上的策略实现也会有不同，这些不同会导致很多意想不到的问题。
基于上述两点，我们考虑做用 C 语言做统一网络库，可以运行在不同的平台上，所有的客户端网络策略和调度全部统一。这样极大程度地降低了研发成本，每个需求只需要一个研发同学投入，不同平台升级统一网络库即可。
服务端部分我们做了网关去中心化的架构升级，中心化的网关有两个问题：第一，容量规划的问题，现在整个支付宝网关平台有近万个接口，每次搞活动前都需要评估接口的请求量，但是它们的峰值请求量很难评估，每次都是拍一个大概的容量；另外，网关服务器成本越来越高，每次活动业务量很大，每次都要大量扩容；第二，稳定性问题，API 网关更贴近业务，发布变更还是比较频繁的，有时候因为某个业务而做的变更存在问题，会导致整个网关集群挂掉，影响到所有的业务，无法做到业务级别的隔离。所以我们做了网关去中心化，干掉了「形式」上的网关，把网关上的 API 路由能力前置到最上层的接入网关上，把网关核心功能（比如说验签、会话、限流等）抽成一个 Jar，集成到业务系统上
关于第四代支付宝移动架构演进，我们主要做了两件事情：第一，统一网络库；第二，网关去中心化。
一方面，客户端平台需要覆盖 iOS、Android，此外还有 IOT RTOS 等平台，未来还需要支持更多端。然而每支持一个平台，我们都需要重新开发一套网络库；另一方面，我们的客户端网络库有比较丰富且复杂的策略，我们经常会发现，每个平台上的策略实现也会有不同，这些不同会导致很多意想不到的问题。
基于上述两点，我们考虑做用 C 语言做统一网络库，可以运行在不同的平台上，所有的客户端网络策略和调度全部统一。这样极大程度地降低了研发成本，每个需求只需要一个研发同学投入，不同平台升级统一网络库即可。
服务端部分我们做了网关去中心化的架构升级，中心化的网关有两个问题：第一，容量规划的问题，现在整个支付宝网关平台有近万个接口，每次搞活动前都需要评估接口的请求量，但是它们的峰值请求量很难评估，每次都是拍一个大概的容量；另外，网关服务器成本越来越高，每次活动业务量很大，每次都要大量扩容；第二，稳定性问题，API 网关更贴近业务，发布变更还是比较频繁的，有时候因为某个业务而做的变更存在问题，会导致整个网关集群挂掉，影响到所有的业务，无法做到业务级别的隔离。所以我们做了网关去中心化，干掉了「形式」上的网关，把网关上的 API 路由能力前置到最上层的接入网关上，把网关核心功能（比如说验签、会话、限流等）抽成一个 Jar，集成到业务系统上
展开
评论
点赞
我们网络传输协议最底层是 SSL/TLS，蚂蚁是基于 TLS1.3 自研了 MTLS，上一层是会话层，最开始基于 HTTP，现在基于自研的通信协议 MMTP，最上层是 RPC、SYNC、PUSH 应用层协议。
RPC 解决“请求 - 响应”的通信模式；SYNC 负责“服务器直接推送数据到客户端”的通信模式；PUSH 负责“推传统的 PUSH 弹框通知”。
另外我们还重新定义了 HTTP2，引入 H2+ 私有帧协议，支持了自定义双向通信，HTTP2 现在基本上已经定为下一代通信协议，主流的浏览器都已经支持了。同时我们也引进到移动端，因为它具有多路复用、hpack 高可压缩算法等很多对移动网络友好的特性。
RPC 解决“请求 - 响应”的通信模式；SYNC 负责“服务器直接推送数据到客户端”的通信模式；PUSH 负责“推传统的 PUSH 弹框通知”。
另外我们还重新定义了 HTTP2，引入 H2+ 私有帧协议，支持了自定义双向通信，HTTP2 现在基本上已经定为下一代通信协议，主流的浏览器都已经支持了。同时我们也引进到移动端，因为它具有多路复用、hpack 高可压缩算法等很多对移动网络友好的特性。
展开
评论
点赞
事务的四大特性 ACID
说到事务，就不得不提一下事务著名的四大特性。
原子性
原子性要求，事务是一个不可分割的执行单元，事务中的所有操作要么全都执行，要么全都不执行。
一致性
一致性要求，事务在开始前和结束后，数据库的完整性约束没有被破坏。
隔离性
事务的执行是相互独立的，它们不会相互干扰，一个事务不会看到另一个正在运行过程中的事务的数据。
持久性
持久性要求，一个事务完成之后，事务的执行结果必须是持久化保存的。即使数据库发生崩溃，在数据库恢复后事务提交的结果仍然不会丢失。
注意：事务只能保证数据库的高可靠性，即数据库本身发生问题后，事务提交后的数据仍然能恢复；而如果不是数据库本身的故障，如硬盘损坏了，那么事务提交的数据可能就丢失了。这属于『高可用性』的范畴。因此，事务只能保证数据库的『高可靠性』，而『高可用性』需要整个系统共同配合实现。
事务的隔离级别
这里扩展一下，对事务的隔离性做一个详细的解释。
在事务的四大特性ACID中，要求的隔离性是一种严格意义上的隔离，也就是多个事务是串行执行的，彼此之间不会受到任何干扰。这确实能够完全保证数据的安全性，但在实际业务系统中，这种方式性能不高。因此，数据库定义了四种隔离级别，隔离级别和数据库的性能是呈反比的，隔离级别越低，数据库性能越高，而隔离级别越高，数据库性能越差。
说到事务，就不得不提一下事务著名的四大特性。
原子性
原子性要求，事务是一个不可分割的执行单元，事务中的所有操作要么全都执行，要么全都不执行。
一致性
一致性要求，事务在开始前和结束后，数据库的完整性约束没有被破坏。
隔离性
事务的执行是相互独立的，它们不会相互干扰，一个事务不会看到另一个正在运行过程中的事务的数据。
持久性
持久性要求，一个事务完成之后，事务的执行结果必须是持久化保存的。即使数据库发生崩溃，在数据库恢复后事务提交的结果仍然不会丢失。
注意：事务只能保证数据库的高可靠性，即数据库本身发生问题后，事务提交后的数据仍然能恢复；而如果不是数据库本身的故障，如硬盘损坏了，那么事务提交的数据可能就丢失了。这属于『高可用性』的范畴。因此，事务只能保证数据库的『高可靠性』，而『高可用性』需要整个系统共同配合实现。
事务的隔离级别
这里扩展一下，对事务的隔离性做一个详细的解释。
在事务的四大特性ACID中，要求的隔离性是一种严格意义上的隔离，也就是多个事务是串行执行的，彼此之间不会受到任何干扰。这确实能够完全保证数据的安全性，但在实际业务系统中，这种方式性能不高。因此，数据库定义了四种隔离级别，隔离级别和数据库的性能是呈反比的，隔离级别越低，数据库性能越高，而隔离级别越高，数据库性能越差。
展开
评论
点赞
ElasticSearch核心概念
集群（Cluster）
一个Elasticsearch集群由多个节点（Node）组成，每个集群都有一个共同的集群名称作为标识
节点（Node）
一个Elasticsearch实例即一个Node，一台机器可以有多个实例，正常使用下每个实例都应该会部署在不同的机器上。Elasticsearch的配置文件中可以通过node.master、node.data来设置节点类型。
node.master：表示节点是否具有成为主节点的资格
true代表的是有资格竞选主节点
false代表的是没有资格竞选主节点
node.data：表示节点是否存储数据
Node节点组合
主节点+数据节点（master+data） 默认
节点既有成为主节点的资格，又存储数据
node.master: true
node.data: true
数据节点（data）
节点没有成为主节点的资格，不参与选举，只会存储数据
node.master: false
node.data: true
客户端节点（client）
不会成为主节点，也不会存储数据，主要是针对海量请求的时候可以进行负载均衡
node.master: false
node.data: false
分片
每个索引有1个或多个分片，每个分片存储不同的数据。分片可分为主分片（primary shard）和复制分片（replica shard），复制分片是主分片的拷贝。默认每个主分片有一个复制分片，每个索引的复制分片的数量可以动态地调整，复制分片从不与它的主分片在同一个 节点上
副本
这里指主分片的副本分片（主分片的拷贝）
提高恢复能力：当主分片挂掉时，某个复制分片可以变成主分片；提高性能：get和search 请求既可以由主分片又可以由复制分片处理
集群（Cluster）
一个Elasticsearch集群由多个节点（Node）组成，每个集群都有一个共同的集群名称作为标识
节点（Node）
一个Elasticsearch实例即一个Node，一台机器可以有多个实例，正常使用下每个实例都应该会部署在不同的机器上。Elasticsearch的配置文件中可以通过node.master、node.data来设置节点类型。
node.master：表示节点是否具有成为主节点的资格
true代表的是有资格竞选主节点
false代表的是没有资格竞选主节点
node.data：表示节点是否存储数据
Node节点组合
主节点+数据节点（master+data） 默认
节点既有成为主节点的资格，又存储数据
node.master: true
node.data: true
数据节点（data）
节点没有成为主节点的资格，不参与选举，只会存储数据
node.master: false
node.data: true
客户端节点（client）
不会成为主节点，也不会存储数据，主要是针对海量请求的时候可以进行负载均衡
node.master: false
node.data: false
分片
每个索引有1个或多个分片，每个分片存储不同的数据。分片可分为主分片（primary shard）和复制分片（replica shard），复制分片是主分片的拷贝。默认每个主分片有一个复制分片，每个索引的复制分片的数量可以动态地调整，复制分片从不与它的主分片在同一个 节点上
副本
这里指主分片的副本分片（主分片的拷贝）
提高恢复能力：当主分片挂掉时，某个复制分片可以变成主分片；提高性能：get和search 请求既可以由主分片又可以由复制分片处理
展开
评论
点赞
用 Redis 做缓存，并不是一说缓存就是 Redis，还是要结合业务的具体情况，我们可以根据不同业务对数据要求的实时性不同，将数据分为三级，以电商项目为例：
第 1 级：订单数据和支付流水数据：这两块数据对实时性和精确性要求很高，所以一般是不需要添加缓存的，直接操作数据库即可。
第 2 级：用户相关数据：这些数据和用户相关，具有读多写少的特征，所以我们使用 redis 进行缓存。
第 3 级：支付配置信息：这些数据和用户无关，具有数据量小，频繁读，几乎不修改的特征，所以我们使用本地内存进行缓存。
选中合适的数据存入 Redis 之后，接下来，每当要读取数据的时候，就先去 Redis 中看看有没有，如果有就直接返回；如果没有，则去数据库中读取，并且将从数据库中读取到的数据缓存到 Redis 中，大致上就是这样一个流程，读取数据的这个流程实际上是比较清晰也比较简单的，没啥好说的。
然而，当数据存入缓存之后，如果需要更新的话，往往会来带另外的问题：
当有数据需要更新的时候，先更新缓存还是先更新数据库？如何确保更新缓存和更新数据库这两个操作的原子性？
更新缓存的时候该怎么更新？修改还是删除？
怎么办？正常来说，我们有四种方案：
先更新缓存，再更新数据库。
先更新数据库，再更新缓存。
先淘汰缓存，再更新数据库。
先更新数据库，再淘汰缓存。
第 1 级：订单数据和支付流水数据：这两块数据对实时性和精确性要求很高，所以一般是不需要添加缓存的，直接操作数据库即可。
第 2 级：用户相关数据：这些数据和用户相关，具有读多写少的特征，所以我们使用 redis 进行缓存。
第 3 级：支付配置信息：这些数据和用户无关，具有数据量小，频繁读，几乎不修改的特征，所以我们使用本地内存进行缓存。
选中合适的数据存入 Redis 之后，接下来，每当要读取数据的时候，就先去 Redis 中看看有没有，如果有就直接返回；如果没有，则去数据库中读取，并且将从数据库中读取到的数据缓存到 Redis 中，大致上就是这样一个流程，读取数据的这个流程实际上是比较清晰也比较简单的，没啥好说的。
然而，当数据存入缓存之后，如果需要更新的话，往往会来带另外的问题：
当有数据需要更新的时候，先更新缓存还是先更新数据库？如何确保更新缓存和更新数据库这两个操作的原子性？
更新缓存的时候该怎么更新？修改还是删除？
怎么办？正常来说，我们有四种方案：
先更新缓存，再更新数据库。
先更新数据库，再更新缓存。
先淘汰缓存，再更新数据库。
先更新数据库，再淘汰缓存。
展开
评论
点赞
当我还不知道如何使用「动态规划」求解时，我会设计一个递归函数 recursiverecursiverecursive 。
函数传入矩阵信息和机器人当前所在的位置，返回在这个矩阵里，从机器人所在的位置出发，到达右下角有多少条路径。
有了这个递归函数之后，那问题其实就是求解 recursive(m,n,0,0)recursive(m, n, 0, 0)recursive(m,n,0,0)：求解从 (0,0) 到右下角的路径数量。
接下来，实现这个函数：
Base case: 由于题目明确了机器人只能往下或者往右两个方向走，所以可以定下来递归方法的 base case 是当已经处于矩阵的最后一行或者最后一列，即只一条路可以走。
其余情况：机器人既可以往右走也可以往下走，所以对于某一个位置来说，到达右下角的路径数量等于它右边位置到达右下角的路径数量 + 它下方位置到达右下角的路径数量。即 recursive(m,n,i+1,j) + recursive(m,n,i,j+1)，这两个位置都可以通过递归函数进行求解。
其实到这里，我们已经求解了这个问题了。
但这种做法还有个严重的“性能”问题。
2：记忆化搜索
如果将我们上述的代码提交到 LeetCode，会得到 timeout 的结果。
可见「暴力递归」的解决方案“很慢”。
我们知道所有递归函数的本质都是“压栈”和“弹栈”。
既然这个过程很慢，我们可以通过将递归版本暴力解法的改为非递归的暴力解法，来解决 timeout 的问题吗？
答案是不行，因为导致 timeout 的原因不在于使用“递归”手段所带来的成本。
函数传入矩阵信息和机器人当前所在的位置，返回在这个矩阵里，从机器人所在的位置出发，到达右下角有多少条路径。
有了这个递归函数之后，那问题其实就是求解 recursive(m,n,0,0)recursive(m, n, 0, 0)recursive(m,n,0,0)：求解从 (0,0) 到右下角的路径数量。
接下来，实现这个函数：
Base case: 由于题目明确了机器人只能往下或者往右两个方向走，所以可以定下来递归方法的 base case 是当已经处于矩阵的最后一行或者最后一列，即只一条路可以走。
其余情况：机器人既可以往右走也可以往下走，所以对于某一个位置来说，到达右下角的路径数量等于它右边位置到达右下角的路径数量 + 它下方位置到达右下角的路径数量。即 recursive(m,n,i+1,j) + recursive(m,n,i,j+1)，这两个位置都可以通过递归函数进行求解。
其实到这里，我们已经求解了这个问题了。
但这种做法还有个严重的“性能”问题。
2：记忆化搜索
如果将我们上述的代码提交到 LeetCode，会得到 timeout 的结果。
可见「暴力递归」的解决方案“很慢”。
我们知道所有递归函数的本质都是“压栈”和“弹栈”。
既然这个过程很慢，我们可以通过将递归版本暴力解法的改为非递归的暴力解法，来解决 timeout 的问题吗？
答案是不行，因为导致 timeout 的原因不在于使用“递归”手段所带来的成本。
展开
评论
点赞
分布式架构的意义
升级单机处理能力的性价比越来越低
单机的处理能力主要依靠 CPU、内存、磁盘。通过更换硬件 做垂直扩展的方式来提升性能，成本会越来越高。
单机处理能力存在瓶颈
单机处理能力存在瓶颈，CPU、内存都会有自己的性能瓶颈， 也就是说就算你是土豪不惜成本去提升硬件，但是硬件的发 展速度和性能是有限制的。
稳定性和可用性这两个指标很难达到
单机系统存在可用性和稳定性的问题，这两个指标又是我们 必须要去解决的
分布式架构的演进
一个成熟的大型应用系统架构并不是一开始就设计得很完美的，也不是一开始就具备高性能、高可用、安全性等特性，而且随着业务数据量的增加而逐步完善的。在这个过程中，开发模式，技术架构都会发生比较大的变化。而针对不同业务的系统，会有各自的侧重点，比如电商平台的网站，要解决的是海量商品搜索、下单、支付等问题。通信软件需要解决的是数亿用户的实时消息传输。搜索引擎要解决的是海量数据的搜索。每一个种类的业务都有自己不同的系统架构。
这里通过一个 javaweb 电商应用来模拟一个架构的演变过程。这个模拟过程关注的是数据，访问量提升带来的结构变化，不关注具体的业务点。
假设我们的系统具有如下功能：
用户功能：用户注册和管理。
商品功能：商品展示和管理。
交易功能：创建交易和支付结算。
升级单机处理能力的性价比越来越低
单机的处理能力主要依靠 CPU、内存、磁盘。通过更换硬件 做垂直扩展的方式来提升性能，成本会越来越高。
单机处理能力存在瓶颈
单机处理能力存在瓶颈，CPU、内存都会有自己的性能瓶颈， 也就是说就算你是土豪不惜成本去提升硬件，但是硬件的发 展速度和性能是有限制的。
稳定性和可用性这两个指标很难达到
单机系统存在可用性和稳定性的问题，这两个指标又是我们 必须要去解决的
分布式架构的演进
一个成熟的大型应用系统架构并不是一开始就设计得很完美的，也不是一开始就具备高性能、高可用、安全性等特性，而且随着业务数据量的增加而逐步完善的。在这个过程中，开发模式，技术架构都会发生比较大的变化。而针对不同业务的系统，会有各自的侧重点，比如电商平台的网站，要解决的是海量商品搜索、下单、支付等问题。通信软件需要解决的是数亿用户的实时消息传输。搜索引擎要解决的是海量数据的搜索。每一个种类的业务都有自己不同的系统架构。
这里通过一个 javaweb 电商应用来模拟一个架构的演变过程。这个模拟过程关注的是数据，访问量提升带来的结构变化，不关注具体的业务点。
假设我们的系统具有如下功能：
用户功能：用户注册和管理。
商品功能：商品展示和管理。
交易功能：创建交易和支付结算。
展开
评论
点赞
算法
在计算机领域里，算法是一系列程序指令，用于处理特定的运算和逻辑问题。 衡量算法优劣的主要标准是时间复杂度和空间复杂度。
数据结构
数据结构是数据的组织、管理和存储格式，其使用目的是为了高效地访问和修改数据。 数据结构包含数组、链表这样的线性数据结构，也包含树、图这样的复杂数据结构。
时间复杂度
时间复杂度是对一个算法运行时间长短的量度，用大O表示，记作 T(n)=O(f(n))。 常见的时间复杂度按照从低到高的顺序，包括O(1)、O(logn)、O(n)、 O(nlogn)、O(n2 )等。
空间复杂度
空间复杂度是对一个算法在运行过程中临时占用存储空间大小的量度，用大O表 示，记作S(n)=O(f(n))。 常见的空间复杂度按照从低到高的顺序，包括O(1)、O(n)、O(n2 )等。其中递 归算法的空间复杂度和递归深度成正比。
线性数据结构
数组
数组对应的英文是array，是有限个相同类型的变量所组成的有序集合，数组中的每一个变量被称为元素。数组是最为简单、最为常用的数据结构。
在计算机领域里，算法是一系列程序指令，用于处理特定的运算和逻辑问题。 衡量算法优劣的主要标准是时间复杂度和空间复杂度。
数据结构
数据结构是数据的组织、管理和存储格式，其使用目的是为了高效地访问和修改数据。 数据结构包含数组、链表这样的线性数据结构，也包含树、图这样的复杂数据结构。
时间复杂度
时间复杂度是对一个算法运行时间长短的量度，用大O表示，记作 T(n)=O(f(n))。 常见的时间复杂度按照从低到高的顺序，包括O(1)、O(logn)、O(n)、 O(nlogn)、O(n2 )等。
空间复杂度
空间复杂度是对一个算法在运行过程中临时占用存储空间大小的量度，用大O表 示，记作S(n)=O(f(n))。 常见的空间复杂度按照从低到高的顺序，包括O(1)、O(n)、O(n2 )等。其中递 归算法的空间复杂度和递归深度成正比。
线性数据结构
数组
数组对应的英文是array，是有限个相同类型的变量所组成的有序集合，数组中的每一个变量被称为元素。数组是最为简单、最为常用的数据结构。
展开
评论
点赞
数据库(Database)就是按照数据结构来组织，存储和管理数据的仓库
专业的数据库是专门对数据进行创建，访问，管理，搜索等操作的软件，比起我们自己用文件读写的方 式对象数据进行管理更加的方便，快速，安全
2，作用
对数据进行持久化的保存
方便数据的存储和查询，速度快，安全，方便
可以处理并发访问
更加安全的权限管理访问机制
3，常见的数据库
数据库分两大类，一类是 关系型数据库。另一类叫做 非关系型数据库。
关系型数据库： MySQL（已被Oracle收购），Oracle，PostgreSQL，SQLserver
使用方法:
方式一: 通过在命令行敲命令来操作 ( 有助于命令的掌握)
方式二: 通过图型界面工具,如 Navicat 等(在熟练掌握后再使用)
方式三：通过编程语言(python,php,java,go...)执行mysql命令
SQL ( Structure query language ) 结构化查询语言
SQL语言分为4个部分：DDL（定义）、DML（操作）、DQL（查询）、DCL（控制）
SQL语句中的快捷键
\G 格式化输出（文本式，竖立显示）
\s 查看服务器端信息
\c 结束命令输入操作
\q 退出当前sql命令行模式
\h 查看帮助
专业的数据库是专门对数据进行创建，访问，管理，搜索等操作的软件，比起我们自己用文件读写的方 式对象数据进行管理更加的方便，快速，安全
2，作用
对数据进行持久化的保存
方便数据的存储和查询，速度快，安全，方便
可以处理并发访问
更加安全的权限管理访问机制
3，常见的数据库
数据库分两大类，一类是 关系型数据库。另一类叫做 非关系型数据库。
关系型数据库： MySQL（已被Oracle收购），Oracle，PostgreSQL，SQLserver
使用方法:
方式一: 通过在命令行敲命令来操作 ( 有助于命令的掌握)
方式二: 通过图型界面工具,如 Navicat 等(在熟练掌握后再使用)
方式三：通过编程语言(python,php,java,go...)执行mysql命令
SQL ( Structure query language ) 结构化查询语言
SQL语言分为4个部分：DDL（定义）、DML（操作）、DQL（查询）、DCL（控制）
SQL语句中的快捷键
\G 格式化输出（文本式，竖立显示）
\s 查看服务器端信息
\c 结束命令输入操作
\q 退出当前sql命令行模式
\h 查看帮助
展开
评论
点赞
互联网协议介绍
互联网的核心是一系列协议，总称为”互联网协议”（Internet Protocol Suite），正是这一些协议规定了电脑如何连接和组网。我们理解了这些协议，就理解了互联网的原理。由于这些协议太过庞大和复杂，没有办法在这里一概而全，只能介绍一下我们日常开发中接触较多的几个协议。
互联网分层模型
互联网的逻辑实现被分为好几层。每一层都有自己的功能，就像建筑物一样，每一层都靠下一层支持。用户接触到的只是最上面的那一层，根本不会感觉到下面的几层。要理解互联网就需要自下而上理解每一层的实现的功能。
物理层
我们的电脑要与外界互联网通信，需要先把电脑连接网络，我们可以用双绞线、光纤、无线电波等方式。这就叫做”实物理层”，它就是把电脑连接起来的物理手段。它主要规定了网络的一些电气特性，作用是负责传送0和1的电信号。
互联网的核心是一系列协议，总称为”互联网协议”（Internet Protocol Suite），正是这一些协议规定了电脑如何连接和组网。我们理解了这些协议，就理解了互联网的原理。由于这些协议太过庞大和复杂，没有办法在这里一概而全，只能介绍一下我们日常开发中接触较多的几个协议。
互联网分层模型
互联网的逻辑实现被分为好几层。每一层都有自己的功能，就像建筑物一样，每一层都靠下一层支持。用户接触到的只是最上面的那一层，根本不会感觉到下面的几层。要理解互联网就需要自下而上理解每一层的实现的功能。
物理层
我们的电脑要与外界互联网通信，需要先把电脑连接网络，我们可以用双绞线、光纤、无线电波等方式。这就叫做”实物理层”，它就是把电脑连接起来的物理手段。它主要规定了网络的一些电气特性，作用是负责传送0和1的电信号。
展开
评论
点赞