当我就是不想用lambda构造器和条件构造器时，我可以按 id 来更新数据：
从最基本层面看，数据库只需做两件事：向它插入数据肘，它就保存数据之后查询时，返回那些数据本文讨论如何存储输入的数据，并在收到查询请求时，如何重新找到数据。为何关注数据库内部的存储和检索呢？你不可能从头开始实现存储引擎，往往需要从众多现有的存储引擎中选择适合业务的存储引擎。 为针对特定工作负载而对数据库调优时，就得对存储引擎底层机制有所了解。针对事务型工作负载、分析型负载的存储引擎优化存在很大差异。
多对多关系是不同数据模型之间的重要区别特征。若数据大多是一对多（树结构数据）或记录之间无关系，则文档模
没有一成不变的系统需求，想法和目标在不断变化：适配新外部环境，新用例，业务优先级变化，用户要求新功能，新平台取代旧平台，法律或监管要求变化，业务增长促使架构演变等。组织、流程方面 ，敏捷开发模式为适应变化提供了很好参考。敏捷社区还发布了很多技术工具和模式，以帮助在频繁变化的环境中开发软件，例如TDD和重构。这些敏捷开发技术多数还只是针对小规模、本地模式（例如同一应用程序中的几个源代码文件）环境。我
软件大部分成本其实不在最初开发阶段，而是在于整个生命周期内的持续投入，包括维护与bug修复，监控系统来保持正常运行、故障排查、适配新平台、搭配新场景、技术缺陷完善及增加新功能。可惜许多程序员不喜欢维护这些所谓的遗留系统，例如修复他人埋下的bug或使用过时的开发平台或被迫做不喜欢的工作。每个遗留系统总有过期理由，所以很难给出通用建议该如何对待它们。但换个角度，可从软件设计时就开始考虑，尽可能减少维护
每人都有直观认识，即什么代表可靠或不可靠。对于软件，典型的期望包括：应用程序执行用户所期望的功能可容忍用户出现错误或不正确的软件使用方法性能可应对典型场景、合理负载压力和数据量系统可防止任何未经授权的访问和滥用上述目标都支持才算 “正常工作”，那么我们可以认为可靠性代表：即使发生某些错误，系统仍可继续正常工作。可能出错的事情称为错误（ fault ）或故障，系统可应对错误称为容错（fault to
即使系统现在可靠，不代表将来一定可靠。发生退化的最常见原因是负载增加：并发用户从最初的10,000 增长到 100,000或系统目前处理数据量超出之前很多倍。可扩展性，描述系统应对负载增加的能力。它不是衡量一个系统的一维指标， 谈论“系统X是可扩展 ”或“不扩展”无太大意义。相反，讨论可扩展性通常得考虑：“若系统以某种方式增长，应对措施有啥”， “该如何添加计算资源来处理额外的负载”3.1 描述负
1 简介一般客户端通过目标类的接口访问它所提供的服务。有时，现有类可以满足客户端类的需要
1 简介Flyweight Design Pattern，结构型模式。享元模式中的“享元”指被共享的单元。享元模式通过复用对象，以达到节省内存的目的。用于减少创建对象的数量，以减少内存占用和提高性能。尝试复用现有的同类对象，如果未找到匹配的对象，则创建新对象。意图：运用共享技术有效地支持大量细粒度的对象。主要解决：在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务
1 简介一般有两种方式给一个类或对象新增行为：继承 子类在拥有自身方法同时还拥有父类方法。但这种是静态的，用户无法控制增加行为的方式和时机关联 将一个类的对象嵌入另一个对象，由另一个对象决定是否调用嵌入对象的行为以便扩展自身行为，这个嵌入的对象就叫做装饰器(Decorator)2 定义结构型模式。动态给一个对象增加额外功能，装饰器模式比生成子类实现更为灵活。装饰模式以对用户透明的方式动态给一个对象
1 定义Bridge Design Pattern，将抽象部分与它的实现部分分离，使之任意删减，而无需受其它约束。Decouple an abstraction from its implementation so that the two can vary independently，将抽象和实现解耦，让它们可以独立变化。2 结构Abstraction： 定义抽象类的接口,维护一个指向Imple
1 前言有时一个对象的行为取决于一或多个动态变化的属性（状态），这样的对象称为有状态(stateful)对象，其对象状态是从事先定义好的一系列值中取出。当这样的对象与外部事件产生互动时，内部状态就会改变，对象行为也随之变化。在UML中可使用状态图描述对象状态的变化。在状态模式中，创建表示各种状态的对象和一个行为随着状态对象改变而改变的 context 对象。2 定义该模式下，类的行为基于其状态而改
看着自己每次根据设计原则及模式的代码重构，虽然效果还不错，但你肯定也自省过：如果我的每段代码都这么写，是不是过度设计了？把握设计的度，确需长久锤炼。行业也总结了很多原则，帮助我们把握设计的度。它们是一种思考方法、一种行为准则。KISSKeep it simple, stupid，保持简单、愚蠢。提醒我们大多数系统，与其变得复杂，保持简单能让系统运行更好。越资深的人，越觉得这大有道理。因为大佬们见识
若 Spring 检测到 bean 实现了 Aware 接口，则会为其注入相应的依赖。所以通过让bean 实现 Aware 接口，则能在 bean 中获得相应的 Spring 容器资源。Aware接口是回调，监听器和观察者设计模式的混合，它表示bean有资格通过回调方式被Spring容器通知。 有时，我们得在 Bean 的初始化中使用 Spring 框架自身的一些对象来执行一些操作，比如获取 Se
间隙锁+行锁，很容易判断是否会出现锁等待。而间隙锁在可重复读隔离级别（RR）下才有效，因此本文默认RR。1 加锁规则原则1 加锁的基本单位：next-key lock，前开后闭原则2 查找过程中，【访问到的对象】才会加锁，加的默认的next-key lock优化1 索引上的等值查询，给【唯一索引】加锁时，next-key lock退化为行锁（记录锁）优化2 索引上的等值查询，【非唯一索引】向右遍历
基于贫血模型的传统开发模式基于充血模型的DDD开发模式如何分别用这两种开发模式，设计实现一个钱包系统。1 业务分析具有支付、购买功能的应用（如京东、哈啰出行）都支持钱包功能。应用为每个用户开设一个系统内的虚拟钱包账户，支持用户充值、提现、支付、冻结、透支、转赠、查询账户余额、查询交易流水。钱包功能界面：每个虚拟钱包账户都对应用户的一个真实的支付账户，如银行卡账户、三方支付账户（支付宝、微信钱包）。
“这代码真烂”或“代码写得真好”。这描述太笼统，具体怎么烂了、怎么就好了？也有一些工程师对如何评价代码质量有所认识，如好代码易扩展、易读、简单、易维护，但更深入的，“怎么算可读性好？代码怎么算易扩展、易维护？可读、可扩展与可维护之间有什么关系？可维护中‘维护’两字该如何理解？”如果连啥是好代码、烂代码，都分不清，又谈何写好代码？如何评价代码质量的高低？对代码质量的一种描述：“好”笼统地表示代码质量
看了很多基础的书籍，比如操作系统、组成原理、编译原理等，但还是觉得很迷茫，觉得在开发中用不上，起码在平时的CRUD业务开发中用不上。实际上，这些基础的知识确实很难直接转化成开发“生产力”。但是，它能潜移默化地、间接地提高你对技术的理解。不过，我觉得，设计模式和操作系统、组成原理、编译原理等这些基础学科是不一样的。它虽然也算是一门基础知识，但是它和数据结构、算法更像是一道儿的，相比那些更加基础的学科
开始日期："2021-08-31"结束日期："2021-11-30"在上述两个日期之间的91天持续时间，期望代码返回3个月的持续时间，但是以下方法仅返回2个月。这是Java 8中的bug 吗？日期为91天，却仅返回2个月。Period diff = Period.between(LocalDate.parse("2021-08-31"), LocalDate.parse("2021-11-
类似 if(Optional.isPresent()) 的条件语句，可以被重写成函数式风格。if (!response.isPresent()) { return Result.success(null);} else { return Result.success(response.get(
# 不会报错，但不会有可用数据返回select name from clase where address ！= null# 这才是正确的SQL!select name from clase where address IS NOT NULL
1 Scenario 场景电商系统的促销手段（Electronic Commerce Systems）：优惠券拼团砍价老带新优惠券的种类满减券直减券折扣券优惠券系统的核心流程发券 发券的方式：同步发送 or 异步发送领券谁能领？所有用户 or 指定的用户 领取上限一个优惠券最多能领取多少张？ 领取方式用户主动领取 or 自动发放被动领取用券作用范围商品、商户、类目 计算方式是否互斥、是否达到门
案例demo 类 起俩线程分别执行add、compare 乍一看，a、b“同时”自增，应该一直相等，compare中的判断不会为true。但是看日志：不仅有a<b成立，a>b有时也为 true。 评论里肯定有人在这里就笑了，这是你的代码太垃圾，操作两个字段a和b，有线程安全问题，应该为add方法加上锁，确保a和b的++是原子性的，就不会错了。那么，就在add方法加锁看看？public
通过监控的报表和一些报警规则的设置，你能实时跟踪和解决垂直电商系统中出现的问题。但监控只能发现目前系统中已存问题，对未来可能发生性能问题无能为力。一旦你的系统流量有大长，比如大促活动流量，那你在面临性能问题时就可能手足无措。你需要了解在流量增长若干倍时，系统的哪些组件或者服务会成为整体系统的瓶颈点，这时你就需要做一次全链路压测。1 压力测试是啥？1.1 错误的压测姿势搭建一套与生产环境功能相同的测
Redis事务和乐观锁原理详解得益于Redis单线程模型的内存处理，没有并发事务，所以无隔离级别概念。1 事务命令1.1 MULTIMUIIT命令执行，标识一个事务的开始，它总返回 OK 。收到该命令后，Redis就知道，接下来再收到的命令需要放到一个内部队列，当EXEC命令被调用时，所有队列中的命令才会被执行，保证原子性。1.2 EXEC表示一系列原子性操作的结束。Redis收到该命令，表示所有
增长黑客，利用数据、技术、产品等一系列手段为互联网产品获得快速用户增长的人。互联网访问没有边界，用户量的增加对应成本的增加也几乎可以忽略不计，所以如何快速、大规模获取用户是互联网产品的成功之道，我们所熟知的成功的互联网公司，例如国内的BAT、国外的FLAG，都拥有数亿甚至数十亿的用户。如何才能获得用户呢？传统打广告，媒体曝光，向用户推销。但投入大、见效慢，不能满足互联网产品增长要求，互联网产品必须
数据之中蕴藏关系，数据量足够大，这种关系越逼近真实世界客观规律。网页之间链接关系蕴藏着网页重要性排序关系，购物车商品清单蕴藏着商品关联关系，通过对这些关系的挖掘，可帮助我们更清晰世界规律，并利用规律提高生产效率，改造世界。挖掘数据的典型应用场景有搜索排序、关联分析以及聚类。搜索排序Hadoop最早源于Goo
数据分析，大数据应用的一个主要场景，通过数据分析指标监控企业运营状态，及时调整运营和产品策略。大数据平台上运行的绝大多数大数据计算都是关于数据分析的，各种统计、关联分析、汇总报告，都需要大数据平台。运营监控那些运营数据指标，老板需要全面快速了解这些指标，以发现公司运营问题。公司角度，运营数据是公司运行发展
稍具规模的互联网企业都会搭建自己的大数据平台。但更多的中小企业和初创公司，自己搭建大数据平台的成本高。拿开源软件搭建自己的大数据平台，对于中小企业来说，无论是人才储备还是服务器成本，都难以承受。别急，还有商业大数据平台供选择。大数据解决方案提供商Hadoop开源产品，关注大数据技术实现和产品功能。但要把Hadoop技术产品在企业真正应用，还有很多事：企业目前技术体系如何与Hadoop集成，具体如何
产品设计中，经常会遇到哪种产品设计方案更优：按钮大点还是小点好；页面复杂点好还是简单点好；这种蓝色还是另一种蓝好；新推荐算法是不是效果真好…这种讨论会出现在运营人员和产品经理之间，也会出现在产品经理和工程师之间，有时候甚至会出现在公司最高层，成为公司生死存亡的战略决策。A/B测试是大型互联网应用的常用手段。如说设计主观，那数据是客观的，与其争执哪种设计更好、哪种方案更受用户欢迎，不如通过A/B测试
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
