cache

计算机访问数据经常会呈现出局部性原理,包括空间局部性和时间局部性

  • 空间局部性:,计算机访问数据,存储在邻近的数据也经常会被访问
  • 时间局部性:相对的一小段时间内,计算机经常会访问相同的数据

计算机从硬盘中读块,不会只读你要的特定块,附近的快很有可能接下来要被访问,会把这些块也一起预读出来

接下来要读附近的快的时候,就不需要再访问硬盘了。这样,运用局部性原理就减少了访问磁盘的次数。附近的块就被缓存了起来,加快了运行速度

网站架构的伸缩性设计

1.1 不同功能物理分离实现伸缩

纵向分离

业务流程不同部分分离部署,实现伸缩

横向分离

不同业务模块分离部署,实现伸缩

1.2 单一功通过集群规模实现伸缩

应用服务器集群性和数据服务器集群伸缩,对数据状态管理的不同,技术实现有很大区别

一头牛拉不动车的时候,不要去寻找一头更强壮的牛,而是用两头牛来拉车

mysql explain

一个常见的理解错误:mysql在执行explain时不会执行sql语句,事实上如果查询的from字段有子查询,explain会执行子查询

explain只能解释select查询,对update,delete,insert需要重写为select

当我们在讨论架构时,该用什么姿势?

架构的本质

任何系统,自然情况下,都是从有序到无序

热力学第二定律,自然界一切自发过程都有方向性,孤立系统由有序变为无序,即它的熵不断增加,最终寂灭

但生物可以通过和外界交互,主动进行新陈代谢,制造 “负熵” 来保证自身有序,继续生存

同样,软件随着功能增多,调用量增长,逐渐碎片化,越来越无序,最终无法维护和扩展,所以系统在一段时间的野蛮生长后,也需要及时干预,避免越来越无序

架构的本质就是对系统进行有序化重构,不断减少系统的 “熵”,使系统不断进化

架构是如何实现无序到有序的? 基本的手段就是分和合,先把系统打散,然后重新组合

《深入理解计算机系统》

万丈高楼平地起,计算机系统就像程序员金字塔的地基。理解了计算机系统的构造原理,在写程序的道路上才能越走越远

道理很早就懂,一直没下定决心好好钻研,或许觉得日常工作中根本用不到这些,又或许是每次拿起书看到那些复杂的底层架构,看到存储器,寄存器,CPU,总线等等这些概念就头大

db

James Gray或JimGray,Jim是James的昵称

Transaction发明人,图灵奖

Gray进入数据库领域时,关系数据库基本理论已成熟,但各大厂RDBMS遇到一系列技术问题,数据库规模,数据库结构复杂,更多用户共享数据库情况下,如何保障完整性(Integrity)、安全性(Security)、并行性 (Concurrency),及故障后恢复 (Recovery)

扫码登陆

通过二维码,用可信任设备(如自己手机)控制不可信任设备上的登录行为

省去不便手动输入的设备(如电视)上输入的环节,更方便

避免在安全等级低的设备和环境(公共电脑、Web页面)输入密码,更安全

cap

分布式系统的事务一致性是一个技术难题

OLTP系统领域,很多业务场景都会面临事务一致性方面的需求,最经典转账的案例

传统企业开发,系统往往是以单体应用形式存在,没有横跨多个数据库

通常只需借助开发平台中特有数据访问技术和框架(Spring、JDBC、ADO.NET),结合rdbms自带事务管理机制来实现事务性的需求(ACID)

互联网平台往往由一系列分布式系统构成,开发语言平台和技术栈也相对比较杂,尤其微服务架构盛行,看起来简单的功能,内部可能需要调用多个“服务”并操作多个数据库或分片来实现,情况复杂很多

单一技术手段和解决方案,无法应对和满足这些复杂的场景

java nio

网上资料很多以IO五种模型为基础讲解NIO

  • 五种模型又涉及很多概念:同步/异步/阻塞/非阻塞/多路复用而不同的人又有不同的理解方式

  • select/epoll/poll/pselectfd这些关键字,没有相关基础的人看起来简直是天书

导致初学时认为nio远不可及

java 学习

摘点关于学j2ee一篇文,适当地参考一下

有部分人觉得J2EE体系太大,直接转投其他阵营了。。。

MySQL 8

16年IMG大会就知道了下一版是8.x

新特性值得抄几篇文章记一下

封装

封装原则倡导通过隐藏抽象的实现细节隐藏变化等,实现关注点分离和信息隐藏

container

容器技术和虚拟机一样,也是一种资源隔离的虚拟化技术。技术雏形早已有之

rpc问题

系统搭建初期,需求简单,架构简单,请求量少,快速原型开发,对rpc要求不高

随便找一个顺手的或者熟悉的rpc框架套进系统中即可

随业务复杂度增高,请求量增高,RPC框架一些致命的问题,比如大扇出问题

每一次请求,上游服务都要获取下游A~Z,26个服务的结果,然后把这26个结果拼装返回给前端

一个业务复杂的系统经过服务拆分,最后拆成一些高内聚低耦合的独立服务,非常容易达到这样一个服务种类数,26还远远不是很多