暂时未有相关云产品技术能力~
关注公众号:JavaEdge,后台回复面试,领取更多大厂求职资源。曾在百度、携程、华为等大厂搬砖,专注Java生态各种中间件原理、框架源码、微服务、中台等架构设计及落地实战,只生产硬核干货!
增加资源,通过添加指令缓存和数据缓存,让我们对于指令和数据的访问可以同时进行。帮助CPU解决取指令和访问数据之间的资源冲突。
Disruptor通过缓存行填充,利用CPU高速缓存,只是Disruptor“快”的一个因素,快的另一因素是“无锁”,尽可能发挥CPU本身的高速处理性能。
随系统规模逐渐增长,总会遇到更换数据库问题。 对MySQL分库分表后,需要从原来的单实例数据库迁移到新的数据库集群 系统从传统部署方式向云上迁移的时候,也需要从自建的数据库迁移到云数据库
数据量太大,单存储节点存不下,就只能把数据分片存储。
保存像图片、音视频这类大文件就是对象存储。不仅有很好的大文件读写性能,还可通过水平扩展实现近乎无限容量,并兼顾服务高可用、数据高可靠。
系统设计得再好,如不能及时完成业务处理也不行。为什么不同业务有不同优化需求,以及常见的优化方式和问题有哪些。
为什么用关系型数据库?最常见的理由是别人在用,所以我也得用,但是这个并不是理由,而是借口。
对系统要求高,通常按金融级标准设计。金融数据传输要求速度快,流量大,极强容灾。
金融行业赚钱的方法有很多,最核心的原理只有:利用信息不对称赚钱。 信息有很多不对称方式,用到的系统工具也都不一样。
应用场景明确,主要在接口设计方面,以兼顾接口的易用性、通用性。
kafka生产者罢工,停止生产,生产者内存急剧升高,导致程序几次重启。 查看日志,发现Pro程序爆异常kafka.common.MessageSizeTooLargeException。
把volatile当成一种锁机制,认为给变量加上了volatile,就好像是给函数加sychronized,不同的线程对于特定变量的访问会去加锁 把volatile当成一种原子化的操作机制,认为加了volatile之后,对于一个变量的自增的操作就会变成原子性
事务的原子性、持久性可确保在一个事务内,更新多条数据都成功/失败。在一个系统内部,我们可以使用数据库事务来保证数据一致性。那如果一笔交易,涉及到跨多个系统、多个数据库的时候,用单一的数据库事务就没办法解决了。事务的原子性、持久性可确保在一个事务内,更
在用户选购商品时,下单前,暂存用户想购买的商品。 购物车对数据可靠性要求不高,性能也无特别要求,在整个电商系统是相对容易设计和实现的一个子系统。
实际的软件开发过程中,常会遇到服务端请求响应时间长,吞吐率不够。 分析对应问题时,你肯定听过“主要瓶颈不在CPU,而在I/O”,存储很重要。
高可扩展性是个设计指标:表示可通过加机器线性提高系统处理能力,承担更高流量和并发。 架构设计之初,为什么不预先考虑好使用多少台机器,支持现有并发呢?因为峰值流量不可控。
系统具备较高的无故障运行的能力。 Hadoop1.0的NameNode是单点,一旦故障,整个集群不可用。Hadoop2提出的NameNode HA方案就是同时启动两个NameNode:
Tomcat整体架构基于组件,可通过XML或代码配置组件。如server.xml配置Tomcat的连接器及容器组件。 Tomcat提供一堆积木,怎么搭建这些积木你决定,你可根据需要灵活选择组件搭建你的Web容器,并且可自定义组件。
MapReduce简化大数据编程难度,但对经常需大数据计算的人,如从事研究BI的数据分析师,他们通常使用SQL进行大数据分析和统计,MapReduce编程还是有门槛。且若每次统计和分析都开发相应MapReduce程序,成本确实太高。
多人同时买一件商品时(假设库存充足),每个人几乎同时下单成功,给人一种并行感觉。但真实情况, 库存只是一个数值,无论是存在mysql数据库还是redis缓存,减值时都要控制顺序,只能串行来扣减,当然为保证安全性,会设计一些锁控制。
说kafka延迟比rocketmq延迟高 是有一个前提的 就是topic较多的时候 这个和这2个MQ的数据存储结构有关系的 在topic少的时候延迟基本一致。
不同物理器件的访问速度不一:速度快的代价高、容量小;代价低且容量大,速度较慢。 为充分发挥各种器件优点,计算机存储数据的物理器件不会只选择一种,而是以CPU为核心,由内而外地组建一整套存储体系结构。它将各种不同的器件组合成一个体系,让各种器件扬长避短,从而形成一种快速、大容量、低成本的内存系统。 写高性能程序,须理解存储体系结构并运用好。
Reactor主线程与长短连接 Broker的 “Reactor” 线程,负责监听网络端口,如监听2888,39150这样的端口。
macOS更新系统后 brew 安装报错不支持pre-release version
索引下推:不符合索引最左前缀原则,却还能利用复合索引的其他字段,减少回表次数。 最左前缀可用于在索引中定位记录。那不符合最左前缀的部分,会怎样
1、书享家(电子书资源导航)http://shuxiangjia.cn/ 2、学吧导航(自学资源导航)https://www.xue8nav.com/ 3、科塔学术(学术资源导航)https://site.sciping.com/
在Kubernetes里部署一个应用的过程。Pod,是Kubernetes项目中最小的API对象。更专业说法,是Kubernetes项目的原子调度单位。
不同的linux发现版厂商习惯性命名64位的方式不一样: ubuntu习惯上称64位为“amd64” fedora习惯上称64位架构为“x86_64”
2.1.1 直接从Pro传递给Con 许多消息传递系统使用Pro和Con之间的直接网络通信,而不通过中间节点
向消费者通知新事件的常用方式 消息传递系统(messaging system):Pro发送包含事件的消息,然后将消息推给Con。
IDEA自动生成serialVersionUID
两个非空链表,表示两个非负整数。它们每位数字都是逆序存储,且每个节点只能存储一位数字。 将两个数相加,并以相同形式返回一个表示和的链表。除了数字 0 之外,这两个数都不会以 0 开头。
大促节零点时,从关注的用户中抽出N个人进行礼品发放,预计全网超过千万用户参加关注抽奖活动,要求: 同一用户不能重复参与 同一用户不允许二次中奖
Redis重视影响Redis性能的因素,如: 命令操作 系统配置 关键机制 硬件配置
新鲜事系统是啥? 各种各样的新鲜事系统,如 Facebook,Twitter,微博,微信朋友圈,以微博为例
实现一个顾客短网址,使得顾客能创立他们自己的短网址。即你需要在前文基础上再实现一个 createCustom。
该系统其实很简单,只需要有一个 service即可:URL Service。由于 tiny url只有一个 UrlService: 本身其实就是个小的独立应用 也无需关心其他任何业务功能
3 Storage 数据存取(最能体现实践经验) select 选存储结构 scheme 细化数据表
如何提高响应速度,和直接打开原链接一样的效率。 明确,这是个读多写少业务。
如脉脉,不会纵容你发太长的网址,会给你转成短链。
这段代码明明很简单,日常跑的都没问题,怎么一大促就卡死甚至进程挂掉?大多是因为设计时,就没针对高并发、高吞吐量case考虑过内存管理。
消息消费失败,很多框架会自动执行重试,而重试就产生了重复消息。 MQTT协议给出三种传递消息时能够提供的
实现最终收敛的一种方案,每个副本总存储最新值,允许覆盖并抛弃旧值。假定每个写请求都最终同步到所有副本,只要确定哪个写入是最新,则副本就能最终收敛到相同值。
多数据中心操作 无主复制也适用于多数据中心操作,因其旨在更好的容忍并发写冲突、网络中断和延迟尖峰等。
若有n个副本,且配置w和r,使得w + r > n w + r> nw+r>n,期望可以读到一个最新值。因为成功写入的节点集合和读取的节点集合必有重合,这样读取的节点中至少有一个具有最新值,如图-11。
图-10中,三副本若有两个以上完成处理,写即可认为成功了。若三副本中只有一个完成写入,会怎样?到底几个副本完成才能认为写成功?
复制的拓扑结构描述了写请求从一个节点传播到另一个节点的通信路径。若有两个主节点,如图-7,只有一个合理拓扑结构:M1必须把他所有的写同步到M2,反之亦然。当有两个以上M,各种不同拓扑都可能的。如图-8说明了一些例子。
主从复制模型的数据更新符合顺序性原则:若同一字段有多个更新,则最后一个写操作决定该字段的终值。
多主复制的最大问题:可能发生写冲突,这是必须要解决的。
之前都是单主的主从复制架构,主从复制有个明显缺点:只有一个主节点,而所有写都必须通过它1。万一和主节点之间的网络中断而导致无法连接到主节点,主从复制方案就影响所有DB写入操作。