暂时未有相关云产品技术能力~
关注公众号:JavaEdge,后台回复面试,领取更多大厂求职资源。曾在百度、携程、华为等大厂搬砖,专注Java生态各种中间件原理、框架源码、微服务、中台等架构设计及落地实战,只生产硬核干货!
1.3 配置新的从节点 有时需考虑新增一个从节点: 提高容错能力 或替换失败的副本节点
复制的重要可选项: 同步复制,synchronously 异步复制,asynchronously
分布式系统中的许多事情可能出错,最简单方法是让整个服务失效,并向用户显示错误消息。若无法接受,就得找到容错方法:即使某些内部组件出现故障,服务也能正常运行。
本系列文章描述了DB并发控制的黯淡: 2PL虽保证了串行化,但性能和扩展不好 性能良好的弱隔离级别,但易出现各种竞争条件(丢失更新,写倾斜,幻读
近30年,DB只有一种广泛使用的串行化算法:两阶段加锁 1 2PL不是2PC 请注意,虽然两阶段锁定(2PL)听起来非常类似于两阶段提交(2PC),但是完全不同概念
RC 和 快照隔离 级别可防止某些竞争条件,但并非全部。一些棘手案例,如写偏斜 和 幻读,会发现可悲情况: 隔离级别难理解,且不同DB实现不一(如RR含义天差地别) 若检查应用层代码很难判断特定隔离级别下是否安全,尤其是大型系统,无法预测各种并发 无检测竞争条件的好工具。理论上,静态分析可能有所帮助,但更多技术还没法实际应用。并发问题测试也很难,一切取决于时机
多个事务并发写相同对象时,会出现脏写、更新丢失两种竞争条件。为避免数据不一致,可: 借助DB内置机制 或通过显式加锁
RC和快照隔离级别主要都是为解决 只读事务遇到并发写时可以看到什么(虽然中间也涉及脏写),还没触及另一种情况:两个写事务并发,而脏写只是写并发的特例。
表面看,RC已满足事务所需的一切特征:支持中止(原子性),防止读取不完整的事务结果,并防止并发写的混乱。这点很关键!为我们的开发省去一大堆麻烦。
若两个事务不触及相同数据,即无数据依赖关系,则它们能安全并行运行。只有当: 某事务读取由另一个事务同时修改的数据时 或两个事务同时修改相同数据
苛刻的数据存储系统中,很多可能出错的case: 数据库软件、硬件可能随时失效(包括正在执行写操作的过程中) 应用程序可能随时崩溃(包括一系列操作的中间某步) 网络中断可能会意外切断数据库与应用的连接,或数据库之间的连接。 多个客户端可能同时写入DB,导致数据覆盖 客户端可能读到无意义的、部分更新的数据 客户端之间由于边界条件竞争所引入的各种奇怪问题
Mac程序坞只显示正在运行的应用图标
随业务井喷,DB出现变化: 查询负载增加,需更多CPU处理负载 数据规模增加,需更多磁盘和内存来存储 节点可能故障,需要其他节点接管失效节点
对大数据集或非常高吞吐量,仅复制还不够,还需将数据拆分成为分区(partitions),也称分片(sharding)1。
根据id更新 当我就是不想用lambda构造器和条件构造器时,我可以按 id 来更新数据
多对多关系是不同数据模型之间的重要区别特征。若数据大多是一对多(树结构数据)或记录之间无关系,则文档模型最合适。但若多对多关系的数据很常见,关系模型能处理简单的多对多,但随数据之间关联复杂度增加,将数据建模转化为图模型更自然。
即使系统现在可靠,不代表将来一定可靠。发生退化的最常见原因是负载增加:并发用户从最初的10,000 增长到 100,000或系统目前处理数据量超出之前很多倍。
1 Scenario 场景 电商系统的促销手段(Electronic Commerce Systems): 优惠券 拼团 砍价 老带新
类似 if(Optional.isPresent()) 的条件语句,可以被重写成函数式风格。
# 不会报错,但不会有可用数据返回 select name from clase where address != null
数据之中蕴藏关系,数据量足够大,这种关系越逼近真实世界客观规律。 网页之间链接关系蕴藏着网页重要性排序关系,购物车商品清单蕴藏着商品关联关系,通过对这些关系的挖掘,可帮助我们更清晰世界规律,并利用规律提高生产效率,改造世界。
数据分析,大数据应用的一个主要场景,通过数据分析指标监控企业运营状态,及时调整运营和产品策略。大数据平台上运行的绝大多数大数据计算都是关于数据分析的,各种统计、关联分析、汇总报告,都需要大数据平台。
大数据技术可分类如下: 存储 计算 资源管理
现代Java应用架构越来越强调数据存储和处理分离,以获得更好的可维护性、可扩展性以及可移植性,比如火热的微服务就是一种典型。这种架构通常要求业务逻辑要在Java程序中实现,而不是像传统应用架构中放在数据库中。
若无法通过并行流实现并发,则必须创建并运行自己的任务。运行任务的理想Java 8方法就是CompletableFuture。 Java并发的历史始于非常原始和有问题的机制,并且充满各种尝试的优化。本文将展示一个规范形式,表示创建和运行任务的最简单,最好的方法。
系统会弹出提示框,让你输入本地用户的密码,输入之后回车即可。 现在密码已经被复制到剪贴板了,随便打开一个可以输入文本内容的文本框,使用快捷键“Command+V”就可以看到WiFi密码!
将使用 JDBC 时间戳转义格式的 String 对象转换为 Timestamp 值。
只能在本地调试查找异常位置,但是在本地调试过程中却可以打印异常堆栈的。后来继续查找之前的日志,之前的某段时间这个地方是存在异常堆栈信息的。
看了 IDEA 的告警: 与 Collections.singletonList 比,使用 Arrays.asList 来生成一个list是否更有优势?后者还能使得返回的list不可变。
显式编码拆箱已包装的原始数值。在Java5及以上的版本,拆箱是不必要的,可以安全地删除。那么 JDK5 到底做了啥
一个数据结构中可能包含多个记录,而这些记录都关联到同一个逻辑数据结构。例如,我可能会读取一系列订单数据,其中有多条订单属于同一个顾客。遇到这样的共享关系,既能将顾客信息作为值对象看待,也能将其视为引用对象
某个类做了应该由两个类做的事。 建立一个新类,将相关的字段和函数从旧类移到新类。
某系统需要对特定的大量用户推送一些消息: 促销活动 让你办卡 有个特价商品
注册、登录、查询、用户信息修改,哪个需求量最大? 支持100M DAU。注册,登录,信息修改 QPS 约 100M * 0.1 / 86400 ~ 100 0.1 = 平均每个用户每天登录+注册+信息修改 Peak = 100 * 3 = 300
基于JSR-330的**@Inject注解将在Jakarta.Inject中。 基于JSR-250的注解@PostConstruct和@Predestroy**将在jakarta.annotation。 暂时,Spring也一直检测到其javax等价物,涵盖预编译的二进制二进制文件中的常用使用。 由于jakarta ee迁移,数据访问和事务,请务必使用Hibernate-Core-Jakarta Artifact升级到Hibernate Orm 5.6.x,以及切换您的javax.persistence接口到jakarta.persistence。
普通索引可重复,唯一索引和主键一样不能重复。 唯一索引可作为数据的一个合法验证手段,例如学生表的身份证号码字段,人为规定该字段不得重复,那么就使用唯一索引。(一般设置学号字段为主键)
比如说有三个字段 a b c,建立复合索引a_b_c。此时叶子节点的数据排序后可能为
1 回表的性能消耗 无论单列索引 or 联合索引,一个索引就对应一个独立的B+索引树,索引树节点仅包含
往InnoDB表新增数据时,都会基于主键给自动建立聚簇索引。 随着我们不停的在表里插入数据,会不停的在数据页里插入数据。一个数据页放满后,就会分裂成多个数据页,这时就需要索引页去指向各个数据页。
刚开始你一个表建好后,就一个数据页,就是聚簇索引的一部分,而且还是空的。若你插入数据,就是直接往这数据页里插入,也没必要给他弄索引页
聚簇索引就是innodb默认创建的基于主键的索引结构,而且表里的数据就是直接放在聚簇索引里,作为叶节点的数据页:
数据页分裂的过程,在你不停往表里灌入数据时,会搞出来一个个数据页,若你的主键非自增,他可能会有一个数据行挪动过程,保证你下一个数据页的主键值都大于上一个数据页的主键值。
文章已收录在我的 GitHub 仓库,欢迎Star/fork: Java-Interview-Tutorial 听说点赞、评论、收藏的人长得都很好看哦。
平时执行的更新语句,都是从磁盘上加载数据页到DB内存的缓存页,接着就直接更新内存里的缓存页,同时还更新对应的redo log写入一个buffer中。
多个事务同时并发更新一行数据时, 就有脏写问题。脏写绝对不允许,可依靠锁机制让多个事务更新一行数据的时候串行化,避免同时更新一行数据。
若 Spring 检测到 bean 实现了 Aware 接口,则会为其注入相应的依赖。所以通过让bean 实现 Aware 接口,则能在 bean 中获得相应的 Spring 容器资源。
支付流程时序图
ERROR 1040(HY000): Too many connections:DB连接池里已有太多连接,不能再和你建立新连接。
MySQL在实际工作时候的两种数据读写机制: 对redo log、binlog这种日志进行的磁盘顺序读写 对表空间的磁盘文件里的数据页进行的磁盘随机读写
执行CRUD都会将磁盘数据页加载到缓存页,那在加载数据到缓存页时,必然是要加载到空闲缓存页,所以必须要从free中找个空闲缓存页,然后把磁盘数据页加载到该空闲缓存页