Spring AOP（面向切面编程）是Spring框架的一个重要组成部分，它允许开发者将通用功能（如日志记录、事务管理等）从业务逻辑中分离出来，从而提高代码的可维护性和重用性。下面，我们将深入探讨Spring AOP的原理。 1. AOP基本概念 切面（Aspect）：一个模块，这个模块包含了多个通知和切点。通知（Advice）：定义了切面在何时以及如何应用增强处理。通知有五种类型：前置通知（Before）、后置通知（After）、返回通知（After-returning）、异常通知（After-throwing）和环绕通知（Around）。切点（Pointcut）：用于定义哪些连接点会被通知应用。连接点（Joinpoint）：在程序执行过程中明确的点，如方法的调用或异常的处理。引入（Introduction）：允许我们向现有的类添加新的方法或属性。织入（Weaving）：将切面应用到目标对象并创建新的代理对象的过程。 2. Spring AOP的实现原理 Spring AOP的实现主要基于代理模式。当为某个对象应用AOP时，Spring会为这个对象创建一个代理对象。这个代理对象会拦截对原对象的调用，并根据切面和通知的定义，在合适的时候执行增强逻辑。 2.1 代理模式 Spring AOP主要使用了两种代理模式：JDK动态代理和CGLIB代理。 JDK动态代理：要求目标对象必须实现一个或多个接口。它利用Java反射机制在运行时创建接口的代理实例。CGLIB代理：可以针对类实现代理，无需实现接口。它通过在运行时扩展字节码来创建子类，然后覆盖目标方法。 2.2 代理对象的创建 Spring AOP使用ProxyFactoryBean或@AspectJ注解来创建代理对象。当启用AOP时，Spring容器会根据配置或注解自动为目标对象创建代理对象。 2.3 切面和通知的解析与织入 解析：Spring容器会解析切面和通知的定义，包括切点表达式和通知类型。织入：在创建代理对象时，Spring会根据切面和通知的定义，将增强逻辑织入到代理对象中。这样，当调用代理对象的方法时，就会触发相应的通知。 3. 总结 Spring AOP通过代理模式和切面编程技术，实现了在不修改原有业务逻辑的情况下，为程序添加额外的功能。它提高了代码的可维护性和重用性，使得开发者能够更专注于业务逻辑的实现。

你是不是总是在幻想在前端使用 StringUtil.isNotBlank 方法，是否对于Date操作而心烦意乱，是否因前端的种种复杂操作而难受至今，那么今天我们就来解决它们。 字符串判断 众所周知，前端判断字符串是否为空，往往都通过感叹号 ! 来完成，但这种方式仅仅只能判断是否为空字符串，对于空白字符无可奈何，还要额外判断，通过百涂工具，就可以这样写： StrUtil.isBlank(""); // 或者 StrUtil.isNoneBlank("", "1", "32"); StrUtil.isAllBlank("dfsa", "dfs"); 方便快捷，同样支持 isEmpty 、 defaultIfBlank 等方法。 月开始或结束时间 DateTime 对象继承了 Date 对象，包含有 Date 的所有方法，是 Date 的升级版，在代码中 DateTime 可替代 Date。 行代码就能获取当月开始或结束时间 DateTime.new().beginOfMonth(); // 创建一个DateTime const dateTime = DateTime.new(); // 获取当月开始时间，输出：2024-03-01 00:00:00 dateTime.beginOfMonth(); // 获取当月结束时间，输出：2024-03-31 23:59:59 dateTime.endOfMonth(); 当然还支持 天、年、星期的开始或结束时间。 一键格式化 格式化时间同样可以一行解决 DateTime.new(2024, 3, 18, 15, 20).formatDateTime(); // 输出：2024-03-18 15:20:00 // 自定义格式化 DateTime.new(2024, 3, 18, 15, 20).format("yyyy年M月d日 HH点mm分"); // 输出：2024年3月18日 15点20分 时间偏移 支持年、月、日、时、分、秒、星期的偏移

👑个人主页：啊Q闻 🎇收录专栏：《C语言》 🎉道阻且长，行则将至 前言 顺序表是我们后续实现通讯录的一个关键技术，今天我们就来学习一下顺序表。 一.顺序表的概念及结构 顺序表是线性表的一种。什么是线性表呢？ 线性表是n个具有相同特性的数据元素的有限序列。线性表是一种在实际中广泛使用的数据结构，常见的线性表有：顺序表，链表，栈，队列，字符串…… 线性表在逻辑结构上是线性结构，在物理结构上不一定是连续的。 线性表在物理上存储时，通常以数组和链式结构的形式存储。 1.对于顺序表，顺序表在逻辑结构上是线性的，物理结构上是连续的。 2.顺序表的底层结构是数组，对数组进行封装，实现常用的增删查改等接口。有点类似与苍蝇馆子包装成五星级酒店。 二.顺序表的分类 顺序表分为静态顺序表和动态顺序表 1.静态顺序表 概念：使用定长数组存储元素 ​ 正是因为静态顺序表是使用定长数组存储元素，所以其空间给少了不够用，给多了又会造成空间浪费。 2.动态顺序表 动态顺序表可以自己开辟空间，相较于静态顺序表更加灵活。 显然，动态顺序表更加灵活好用，我们来完成一下动态顺序表的实现。 三.动态顺序表的实现 动态顺序表的实现要有的基本功能是增删查改，所以我们要实现的功能为顺序表的初始化和销毁，以及基本功能增删查改。 我们创建三个文件： 一个头文件SeqList.h用于定义顺序表的结构，顺序表要实现的接口。 一个源文件SeqList.c用于具体实现顺序表里定义的接口。 一个源文件test.c用于测试顺序表。 SeqList.h #pragma once #include<stdio.h> #include<stdlib.h> #include<assert.h> typedef int SLDataType; typedef struct Seqlist { SLDataType* arr; int size; int capacity; }SL; void Init(SL* ps);//初始化 void SLPlusCapacity(SL* ps);//扩容 void SLPushFront(SL* ps,SLDataType num);//前插 void SLPushBack(SL* ps, SLDataType num);//后插 void SLDeFront(SL* ps);//头删 void SLDeBack(SL* ps);//尾删 void SLInsert(SL* ps, SLDataType num, int pos);//指定位置插入 void SLDelete(SL* ps, int pos);//指定位置删除 int SLFind(SL* ps, SLDataType num);//查找 void SLChange(SL* ps, SLDataType num,int a);//修改 void SLPrint(SL*ps);//打印 void SLDestory(SL* ps);//销毁 详解：

9.1 软件工程管理活动 9.2 软件规模、成本和进度估算 9.3 能力成熟度模型CMM 9.4 ISO 9000系列标准简介 9.5 CMM与ISO 9000系列标准的比较 9.6 本章小结

部分手机会提示（目前已知一加手机会出现该问题），可进入manifest找到App常用其他设置，将minSdkVersion设置的高一点，targetSdkVersion也可以适当提高。 参考数值： targetSdkVersion： 28 minSdkVersion： 26

MySQL中的MyISAM和InnoDB是两种不同的存储引擎，它们在设计理念、功能特点以及应用场景等方面有着显著的差异。以下是它们之间的主要区别： 事务支持： InnoDB：支持事务处理，具有提交、回滚和崩溃恢复能力，这保证了数据的完整性和一致性。对于需要高数据完整性的应用，如银行系统，InnoDB是一个很好的选择。MyISAM：不支持事务处理，也不具有崩溃恢复能力。这意味着在数据更新过程中，如果出现系统崩溃，可能会导致数据不一致。 锁机制： InnoDB：支持行级锁定，这使得在高并发环境下，InnoDB可以更有效地处理多个用户同时读写的情况，提高了并发性能。MyISAM：仅支持表级锁定，这意味着在读写操作时，整个表都会被锁定，这可能会降低并发性能。 外键支持： InnoDB：支持外键约束，这有助于保持数据的引用完整性。MyISAM：不支持外键。 全文索引： InnoDB：在MySQL 5.6及之前的版本中，InnoDB不支持全文索引。但在MySQL 5.6.4及更高版本中，InnoDB开始支持全文索引。MyISAM：支持全文索引，这使其在需要全文搜索的应用中表现更好。 备份与恢复： InnoDB：支持在线热备份，这意味着在备份过程中，数据库仍然可以保持运行状态，提高了系统的可用性。MyISAM：不支持在线热备份，需要在备份时停止数据库的运行。 索引结构： InnoDB：是聚集索引，数据和索引是绑定在一起的，主键索引的效率很高。但辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。MyISAM：是非聚集索引，数据和索引是分开的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。 空间使用与压缩： InnoDB：不保存表的具体行数，执行SELECT COUNT(*) FROM table时需要全表扫描。MyISAM：内部维护了一个计数器，可以直接调取，所以执行SELECT COUNT(*) FROM table更快。同时，MyISAM表格可以被压缩，这有助于节省存储空间。 总的来说，InnoDB和MyISAM各有其优势和适用场景。InnoDB更适用于需要高数据完整性、高并发和事务处理的应用场景，而MyISAM则更适用于读操作频繁、不需要事务处理以及需要全文搜索的应用场景。在选择存储引擎时，应根据具体的应用需求和系统环境进行权衡。

目录 介绍 FlumeFlume 架构请说一下你提到的几种 source 的不同点Flume 传输数据时如何保证数据一致性TailDir 为什么可以断点重传说下Flume事务机制Sink 消费能力弱，Channel 会不会丢失数据数千个Flume要怎么统一配置，修改就分发吗Flume一个节点宕机了怎么办，数据怎么恢复你是如何实现Flume数据传输的监控的Flume的Channel SelectorsFlume参数调优Flume的事务机制Flume采集数据会丢失吗?Flume Kafka Sink了解过吗Flume写到HDFS怎么分区Flume如果出现数据重复是什么原因Flume的配置文件怎么写的 介绍 Flume 可以从以下几个方面回答，每一个方面又可以当做一个面试题 （1）Flume 是什么？ Flume 是 Cloudera 公司提供的一个 高可用的，高可靠的，分布式的 海量日志采集、聚合 和 传输 的系统。Flume 的设计原理是基于数据流（流式架构，灵活简单），其最主要的作用是实时读取服务器本地磁盘的数据，将数据写入HDFS 或 Kafka等。 （2）Flume 文件目录 Flume 主要的文件目录如下： （3）Flume 的 Agent 组件 Flume 内部有一个或者多个 Agent，然而对于每一个 Agent 来说，它就是一个独立的守护进程(JVM)，它从客户端那接收数据，或者从其他的 Agent 那接收，然后迅速的将获取的数据传给 Sink，或者其他 Agent 。每个 Agent 包含了 Source、Channel 和 Sink。 （4）Flume 优缺点 优点 Flume 可以将应用产生的数据存储到任何集中存储器中，比如 HDFS，HBase。当收集数据的速度超过将写入数据的时候，也就是当收集信息遇到峰值时，这时候收集的信息非常大，甚至超过了系统的写入数据能力，这时候，Flume 会在数据生产者和数据收容器间做出调整，保证其能够在两者之间提供一个平稳的数据。提供上下文路由特征。（上下文路由特征是 Flume 提供的一种机制，用于根据事件的上下文信息将数据路由到不同的目的地。）Flume 的管道是基于事务，保证了数据在传送和接收时的一致性。Flume 是可靠的，容错性高的，可升级的，易管理的，并且可定制的。实时性，Flume可以实时的将分析数据并将数据保存在数据库或者其他系统中。 缺点 Flume 的配置很繁琐，source，channel，sink 的关系在配置文件里面交织在一起，不便于管理。无法保证数据的不重复 （5）应用场景

文章目录 Virtio 基本构建块Virtio spec 和 vhost 协议Vhost-net/virtio-net architectureVirtio-networking and OVS总结参考链接 Virtio 是作为虚拟机 (VM)访问简化device（如块设备和网络适配器）的 标准化开放接口而开发的。Virtio-net是一种虚拟以太网卡，是virtio迄今为止支持的最复杂的device。 在这篇文章中，我们将基于在host内核和 VM guest内核之间建立接口，提供 virtio 网络架构的高级解决方案概述。我们将介绍基本的构建块，包括KVM，qemu和libvirt。我们将介绍virtio规范和vhost协议，以及用于连接不同VM和连接外部世界的Open vSwitch（OVS）。本文中描述的基于vhost-net/virtio-net的架构是许多virtio-networking架构中的第一个，这些架构将在一系列帖子中介绍，这些架构因其性能，应用程序的易用性和实际部署而有所不同。 在阅读完这篇文章后，你应该对所提到的术语有一个清晰的了解，以及在虚拟机中运行的应用程序如何将数据包传输到在其他虚拟机上运行的应用程序和外部世界。这些术语将是下一篇文章的基础。 Virtio 基本构建块 guest VM 或guest是在物理计算机上安装、执行和托管的 VM。托管guest VM 的计算机称为host，它为guest提供资源。客户机具有通过虚拟机管理程序在host操作系统上运行的单独操作系统。例如，host将为guest提供虚拟 NIC，以便guest计算机感觉好像它使用的是真正的 NIC，而实际上它使用的是虚拟 NIC。 以下构建基块创建了 virtio 稍后连接到的环境： KVM - 基于内核的虚拟机，允许 Linux 作为管理程序运行，因此主机可以运行多个隔离的虚拟环境，称为Guest。KVM 基本上为 Linux 提供管理程序功能。这意味着管理程序组件，如内存管理器、调度器、网络堆栈等，作为 Linux 内核的一部分提供。VMs 是由标准 Linux 调度器与专用虚拟硬件（如网络适配器）调度的常规 Linux 进程。QEMU - 一个托管的虚拟机监视器，通过仿真为guest计算机提供一组不同的硬件和device型号。QEMU 可与 KVM 配合使用，利用硬件扩展以接近本机的速度运行虚拟机。guest通过 qemu 命令行界面 （CLI） 执行。CLI 提供了为 QEMU 指定所有必要配置选项的功能。Libvirt - 一个将XML格式的配置转换为qemu CLI调用的接口。它还提供了一个管理守护进程来配置子进程（如 qemu），因此 qemu 不需要 root 权限。例如，当Openstack Nova想要启动一个VM时，它使用libvirt为每个VM调用一个qemu进程来启动每个VM的qemu进程。 下图显示了这三个构建基块如何组合在一起：

在Java 8中，synchronized和ReentrantLock都是用于控制多线程对共享对象的访问，确保线程安全性的重要工具。然而，它们之间存在一些关键差异，这些差异影响了它们的使用场景和性能表现。 来源与层次： synchronized是Java语言的关键字，属于JVM级别的锁，是原生语法层面的互斥。ReentrantLock是Lock接口下的一个实现类，是API层面的锁，需要lock()和unlock()方法配合try/finally语句块来完成。 锁的类型： synchronized是非公平锁，按照线程进入的顺序来获取锁，可能会出现线程“饥饿”现象。ReentrantLock默认也是非公平锁，但可以支持并指定公平锁。公平锁保证了线程按照申请锁的顺序来获取锁，避免了线程饥饿问题。 锁的获取与释放： synchronized在代码块前自动加锁，执行完毕后自动释放锁。如果在执行过程中出现异常，JVM会确保锁被正确释放。ReentrantLock需要显式地调用lock()方法来获取锁，并在finally块中调用unlock()方法来释放锁。如果在执行过程中出现异常，必须手动确保锁被正确释放，否则可能导致死锁。 响应中断： synchronized在获取锁的过程中不能响应中断，线程会一直等待下去。ReentrantLock可以响应中断，通过lockInterruptibly()方法尝试获取锁，如果当前线程在等待获取锁的过程中被中断，会抛出InterruptedException，从而解决死锁问题。 锁的可重入性： synchronized和ReentrantLock都是可重入锁，这意味着同一线程可以多次获得同一个锁，而不会导致死锁。 等待可中断与超时： ReentrantLock提供了Condition对象，可以实现等待可中断和超时等待，这在某些场景下比synchronized更灵活。synchronized不支持这些特性。 性能： 在某些场景下，ReentrantLock的性能可能略优于synchronized，因为它提供了更多的灵活性和定制化选项。然而，synchronized作为语言原生支持的特性，在简单场景下通常具有更好的性能。 总的来说，synchronized和ReentrantLock在用法、性能、灵活性等方面都存在差异。在选择使用哪一个时，应根据具体的应用场景和需求进行权衡。对于简单的同步需求，synchronized通常是一个很好的选择；而对于需要更复杂控制或更高性能的场景，ReentrantLock可能更合适。

目录 什么是HBase简述HBase 的数据模型HBase 的读写流程HBase 在写的过程中的region的split的时机HBase 和 HDFS 各自的使用场景HBase 的存储结构HBase 中的热现象（数据倾斜）是怎么产生的，以及解决办法有哪些HBase rowkey的设计原则HBase 的列族设计HBase 中 compact 用途是什么，什么时候触发，分为哪几种，有什么区别hbase 基本架构hbase 和 hive 有什么区别HBase的MemStore的刷写MemStore在刷写磁盘过程中，还可以继续写入吗？Region分裂期间能不能对外提供服务HBase和MySQL的存储结构有什么不同HBase的LSM结构LSM树和B+树做比较LSM树为什么要用布隆过滤器HBase为什么适合写HBase为什么查询快HBase不同写入方式的应用场景？HBase的BulkLoadHBase中的一个节点宕机了怎么办MemStore中排序方法HBase是列式存储吗？行式存储和列式存储有什么区别？HBase的HFile的格式 什么是HBase HBase 是一种 分布式、可扩展、支持海量数据存储 的 NoSQL 数据库，支持对大数据进行随机、实时的读/写访问。 简述HBase 的数据模型 HBase 的数据模型同关系型数据库很类似，数据存储在一张表中，有行有列。 其中 namespace：命名空间，类似于关系型数据库中的 database，每个命名空间下有多个表。HBase 默认有两个命名空间，分别叫做 default 和 hbaseregion：类似于关系型数据库中的 table。但是 HBase 在定义表的时候不需要定义具体的列，只需要定义列族就可以了row：表示一行数据，每行数据有一个 rowkey 和多个列组成，数据是按照 rowkey 的字典顺序排列的column：每一列都有列族和列限定符组成timestamp：用于标识数据的不同版本，每条数据写入的时候，如果不指 定时间戳，默认为写入 HBase 的时间cell 最小单元：由{rowkey, column, timestamp}唯一确定 HBase 的读写流程 读流程 （1）Client 先访问 zookeeper，获取 hbase:meta 表位于哪个Region Server。 （2）访问对应的Region Server，获取 hbase:meta 表，根据读请求的namespace:table/rowkey，查询出目标数据位于哪个Region Server中的哪个Region中。并将该 table 的region信息以及meta表的位置信息缓存在客户端的 meta cache，方便下次访问。 （3）与目标Region Server进行通讯；

在 Java 8 中，ThreadPoolExecutor 提供了四种内置的线程池拒绝策略，这些策略都实现了 RejectedExecutionHandler 接口： AbortPolicy（中止策略）： 这是默认的拒绝策略。当线程池无法处理新任务时，它会直接抛出一个RejectedExecutionException 异常。CallerRunsPolicy（调用者运行策略）： 当线程池无法处理新任务时，它不会抛出异常，而是直接在提交任务的线程中运行该任务。这提供了一种简单的降级机制，但请注意，如果提交任务的线程是一个重要的线程（例如，UI 线程），这可能会导致问题。DiscardPolicy（丢弃策略）： 当线程池无法处理新任务时，它什么也不做，直接丢弃这个任务。DiscardOldestPolicy（丢弃最旧策略）： 当线程池无法处理新任务时，它会丢弃工作队列中最旧的任务，然后尝试重新提交当前任务。 默认的策略是 AbortPolicy，即当线程池无法处理新任务时，它会抛出 RejectedExecutionException 异常。 你可以通过调用 ThreadPoolExecutor 的 setRejectedExecutionHandler 方法来设置你想要的拒绝策略。例如： ThreadPoolExecutor executor = new ThreadPoolExecutor(...); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); 此外，你还可以实现自己的 RejectedExecutionHandler 来定义自己的拒绝策略，并将其设置到线程池中。这为你提供了高度的灵活性，可以根据应用的具体需求来定制拒绝策略。

目录 1 Hbase 概述1.1 Hbase 定义1.2 HBase 数据模型1.2.1 HBase 逻辑结构1.2.2 HBase 物理存储结构1.2.3 数据模型 1.3 HBase 基本架构 2 HBase Shell 操作2.1 基本操作2.2 namespace 操作2.3 表操作 3 HBase 原理深入3.1 RegionServer 架构3.2 HBase 写流程3.3 MemStore Flush3.4 HBase 读流程3.5 StoreFile Compaction3.6 Region Split 4 HBase API5 HBase 优化5.1 预分区5.2 RowKey 设计5.3 内存优化5.4 基础优化 6 整合Phoenix7 与 Hive 的集成 1 Hbase 概述 1.1 Hbase 定义 HBase 是一种 分布式、可扩展、支持海量数据存储 的 NoSQL 数据库，支持对大数据进行随机、实时的读/写访问。 NoSQL数据库（非关系型数据库）是一种不同于传统关系型数据库的数据库管理系统。它们使用灵活的数据模型，不遵循传统的表格关系模式，而是采用键值对（如Redis）、文档型（如MongoDB）、列族存储（如HBase）、图形数据库（如Neo4j）等各种数据模型。非关系型数据库主要用于存储和处理大量分散的数据，具有高性能、高可扩展性和高可用性的特点。 Hadoop中的 HDFS 是不支持随机修改数据的，但可以追加写。HBase 底层基于Hadoop，为什么就可以支持对数据的随机读写了呢？让我们继续往下学习

作者 | Spark源码践行者 导读 introduction 本文介绍了百度数仓融合计算引擎的整体设计原理、优化及实践，阐述了在互联网产品快速迭代的趋势下，基于一层数仓宽表模型的数仓模型如何做到数十秒级查询的技术方案，并从互联网业务变化特性、传统计算引擎存在的问题、融合计算引擎的原理及优缺点、引擎应用场景和效果等角度进行了较为全面的分析，最终通过引擎设计和优化实现了提升查询性能的同时节约数仓存储的目标，降低了用户的数据使用成本。 全文4003字，预计阅读时间11分钟 GEEK TALK 01 业务背景 1.1 数据现状和数据分析引擎的演进 1.1.1 数据现状 互联网企业往往存在多个产品线，每天源源不断产出大量数据，数仓规模达到数百PB以上，这些数据服务于数据分析师、业务上的产品经理、运营、数据开发人员等各角色。为了满足这些角色的各种需求，需要稳定高效的计算引擎在海量数据中快速完成分析计算。 1.1.2数据分析引擎的演进及百度数仓引擎选型 单机分析时代（数仓TB级别）-> MapReduce、Hive基于磁盘的分析时代（数仓数PB级别，分析耗时数十分钟）-> Spark基于内存的分析时代（数仓数百PB，分析耗时数十秒） 百度数仓引擎选型：对比了业界常用的Adhoc查询分析引擎，通过对比Hive生态、大规模Join、存储引擎、列式存储、是否支持高并发以及适用场景等，如图1： △图1 最终选型Spark SQL，因为SparkSQL对Hive生态兼容好，大规模Join性能好，支持大宽表列存，支持UDF等。 1.2 当前业务特性与趋势 互联网产品快速迭代，业务发展越来越快，跨业务分析越来越多，数据驱动业务越来越重要。数仓计算任务和数据量越来越多，adhoc场景日均参与计算的数据数十P，ETL场景日均数十P，数据服务的主要群体正在从数据研发转向分析师、产品及运营人员，查询计算速度需要进一步提升，使用门槛需要进一步降低。 GEEK TALK 02 面临的问题 2.1 在数据驱动业务越来越重要的大趋势下，分析效率越来越重要 面临如下问题，如图2、图3： △图2 △图3 2.2 思考 那么在生产实践中如何解决上述面临的问题及痛点呢，在对数仓技术深度调研和对业务线具体用户访谈后，根据调研和访谈结论，得出以下想法： （1）引擎层面：设计融合计算引擎、使用DataSkipping，Limit下推、Codegen和向量化，参数调优等方式加速数据查询，快速满足业务查询需求，助力数据驱动业务。 （2）数仓层面：数仓不分层，节约数仓整体存储，用更少的表满足业务需求，比如一个主题一张宽表，明确数据表使用方式，确保口径清晰统一，避免业务方线下拉会沟通，降低沟通成本，提高沟通效率。 GEEK TALK 03 技术方案 根据上述的想法，经过可行性分析后，提出设计开发出融合计算引擎和一层大宽表模型替代经典数仓维度模型的技术方案，来解决传统数仓adhoc场景查询性能低、存储大量冗余、表多且口径不清晰的问题。 3.1 融合计算引擎 融合计算引擎是一个百度自研的集常驻、查询、生产于一体的数仓融合的SQL 计算引擎，它基于 Apache Spark 构建，具有快速、可扩展和高度可靠的特性，不仅用于在PB甚至EB级大规模数据处理和分析场景中执行 SQL 查询，也用于例行生产的 ETL 场景。 3.1.1融合计算引擎架构 融合计算引擎架构如下：由WebServer、Master、Worker三部分组成。具体各部分功能见图4： △图4 基于Spark源码二次开发的Worker是核心执行模块，内部Container常驻做到资源复用。 3.1.2 融合计算引擎性能优化 3.1.2.1 如何算的更少DataSkipping （1）PartitionSkipping：仅读取必要的分区，对性能提升最大 （2）Parquet列式存储 百度数据中台线上查询特点是宽表 500~1300列，平均查询列数15列以内，非常适合使用Parquet存储格式，优点是：

智能指针在面试时经常被问到，最近自己也在写，有一点思考，于是找到了这样一个题目，可以看看，上面这个代码有什么问题？留言区说出你的答案吧！ 最后分享一下之前的实习->春招->秋招等文章汇总如下，期待大家留言转发。 个人在实习投了3家，分别是腾讯、阿里、CVTE，三家都拿到了，最后去了腾讯实习，随后实习转正，也拿到了正式的offer。秋招时页面了很多的公司，例如：字节、B站、快手、滴滴等，其中快手、滴滴都拿下来了，也拿到过40w+的offer，50w+的offer，有SP、SSP、白菜等offer，下面便会将这一路的文章总结如下面所示，实习秋招有任何问题可以留言区回复，或者私聊我即可。 实习+春招+秋招篇 1.面试求职必胜法宝 2.快速拿下面试算法 3.腾讯视频实习面经 4.CVTE C/C++开发面经 5.实习准备前奏篇 6.腾讯实习转正总结 7.实习记之把握当下机会比努力更重要 8.秋招总结 9.最宝贵的字节十二面面经，覆盖面试90%知识点！ 10.快手+B站+深信服+Smartx+依图 11.华为6面ssp+滴滴sp+京东面经 鹅厂学习篇 1.鹅厂学习的一周多时光及C++书籍推荐 2.鹅厂学习之Mock Server经验谈 3.鹅厂实习的学与乐 4.实习期间的一些idea 联系方式：

随着信息技术的迅猛发展，智慧城市和数字孪生作为现代城市发展的重要理念和技术手段，正日益受到广泛关注。智慧城市通过集成应用先进的信息通信技术，实现城市管理、服务、运行的智能化，而数字孪生则是利用数字化手段对物理城市进行建模与仿真，以实现对城市运行的全面感知和精准预测。科技融合的智慧城市与数字孪生，不仅提升了城市治理的效率和水平，也为城市的可持续发展注入了新的动力。 一、智慧城市：城市发展的智慧化转型 智慧城市是运用物联网、云计算、大数据、空间地理信息集成等新一代信息技术，促进城市规划、建设、管理和服务智慧化的新理念和新模式。它通过感测、传送、整合城市运行核心系统的各项关键信息，从而对于包括民生、环保、公共安全、城市服务、工商业活动在内的各种需求做出智能的响应，为人类创造更美好的城市生活。 在智慧城市的构建过程中，信息技术发挥着至关重要的作用。物联网技术实现了城市各类设施与设备的互联互通，使得城市管理者能够实时获取城市运行数据；云计算技术为海量数据的存储和处理提供了强大的支持，使得城市管理者能够迅速分析数据，提取有价值的信息；大数据技术则通过深度挖掘城市数据，发现城市运行中的规律和问题，为决策提供科学依据。 智慧城市的建设不仅提升了城市管理的效率，也改善了城市居民的生活质量。通过智能交通系统，城市管理者可以实时调整交通流量，缓解交通拥堵；通过智能电网系统，可以实现对电能的优化分配和高效利用；通过智能医疗系统，可以为居民提供更加便捷和高效的医疗服务。 二、数字孪生：城市运行的虚拟镜像 数字孪生是充分利用物理模型、传感器更新、历史数据等，集成多学科、多物理量、多尺度、多概率的仿真过程，在虚拟空间中完成映射，从而反映相对应的实体装备的全生命周期过程。在城市领域，数字孪生技术通过建立城市的虚拟模型，实现对城市运行的全面感知和精准预测。 数字孪生技术为城市管理者提供了一个全新的视角和工具。通过数字孪生技术，管理者可以在虚拟空间中模拟城市运行的各种场景，预测城市发展的趋势和问题，从而制定更加科学合理的决策。同时，数字孪生技术还可以实现对城市运行的实时监控和预警，帮助管理者及时发现和处理城市运行中的异常情况。 数字孪生技术在城市规划、建设和管理等方面具有广泛的应用前景。在城市规划阶段，数字孪生技术可以帮助规划者模拟不同规划方案的效果，选择最优方案；在城市建设阶段，数字孪生技术可以实现对施工过程的实时监控和优化，提高建设效率和质量；在城市管理阶段，数字孪生技术可以辅助管理者实现对城市资源的优化配置和高效利用。 三、科技融合：推动城市可持续发展 智慧城市与数字孪生的科技融合，为城市的可持续发展提供了强大的动力。通过集成应用先进的信息通信技术，智慧城市与数字孪生实现了对城市运行的智能化管理和精准化决策，提升了城市管理的效率和水平。同时，科技融合还推动了城市产业的转型升级和创新发展，为城市的经济发展注入了新的活力。 在环境保护方面，科技融合的智慧城市与数字孪生可以帮助城市管理者制定更加科学合理的环境保护策略，降低污染排放，提高资源利用效率。通过实时监测城市环境质量，及时发现和处理环境问题，保护城市的生态环境。 在社会治理方面，科技融合的智慧城市与数字孪生可以提升城市治理的智能化水平，增强城市的安全性和稳定性。通过大数据分析和人工智能技术，实现对社会问题的精准识别和快速响应，提高社会治理的效率和效果。 在公共服务方面，科技融合的智慧城市与数字孪生可以为城市居民提供更加便捷、高效、个性化的公共服务。通过智慧医疗、智慧教育、智慧交通等应用，满足居民多元化的需求，提高居民的生活质量。 四、挑战与展望 尽管智慧城市与数字孪生在推动城市可持续发展方面取得了显著成效，但仍面临一些挑战。首先，数据安全和隐私保护问题亟待解决。随着城市数据的不断积累和应用，如何确保数据的安全性和隐私性成为了一个重要的问题。其次，技术标准和规范尚需完善。目前，智慧城市与数字孪生的建设缺乏统一的技术标准和规范，导致不同系统之间的互联互通存在困难。此外，还需要加强人才培养和科技创新，为智慧城市与数字孪生的发展提供有力支撑。 “方案365”全新整理智慧城市、数据治理、智慧农业、智慧应急、数字孪生、乡村振兴、智慧乡村、元宇宙、数据中台、智慧园区、智慧矿山、城市生命线、智慧水利、智慧校园、智慧工地、智慧农业、智慧旅游等300+行业全套解决方案。 展望未来，随着技术的不断进步和应用场景的不断拓展，智慧城市与数字孪生将在更多领域发挥重要作用。我们期待看到更多的科技创新和实践探索，为城市的可持续发展贡献更多智慧和力量。 智慧城市与数字孪生作为科技融合的重要成果，为城市的可持续发展提供了有力支持。通过加强技术研发和应用推广，我们可以期待一个更加智慧、绿色、宜居的未来城市。

100%可行的方法 大家不行是因为没找对地方，确实是修改这个东西就可以了 -Xms512m -Xmx4096m 但是首先要找对idea加载的是哪个配置文件。 找到idea启动文件夹，编辑idea.bat 添加打印修改文件路径的代码，运行idea.bat打印一下你的配置文件路径，找到路径 修改 然后运行idea.bat 找到打印的文件，修改内存就可以了。 OK了

联合解决方案 博思医疗行业电子票据管理系统是面向医疗单位提供门诊、住院、挂号、体检、互联网等医疗电子票据的票据管理、票据开具、财务内控、票据推送等服务的业务系统，有效解决了群众看病缴费难、排队时间长等问题，是一款为医疗单位量身打造，具有高成熟度的业务系统。数据存储采用SinoDB数据库，SinoDB数据库具有极高的处理性能，保障群众高效完成排队缴费；数据库的强一致性的性能，确保各方数据的一致性，避免重复或错误信息，减少患者和医疗提供者的不必要纠纷。 技术架构图692×511 86.2 KB 医疗行业电子票据管理系统总体技术架构图从底层到接入层分了六层： 基础设施层： 是软件运行的必要条件，计算、网络、存储、监控、安全、IDC 平台服务层： 包含图中几个模块，资源治理、集群资源调度配合实际业务场景实现资源充分利用，如业务量暴增时，增加服务，上调资源，需要配合监控告警，理想状态是如何实现自动化，交由系统弹性分配。镜像治理、发布系统帮助实现自动化IAM （ Identity And Access Management）。 支撑服务层： 微服务核心支撑服务。 业务服务层： 分解为基础服务与聚合服务两个维度。 基础服务： 基于单一职责，根据业务特点沉淀与底层的核心基础服务、公共服务、中间层服务。 聚合服务： 很多时候基础服务是可重复利用的，同时也需要支持需求的多变，通过聚合服务将基础服务关联，组件，再封装，可很好实现目标。 网关层： 可根据访问者类型拆分为图中几类。内部的接口无论出于安全、稳定性、还是设计上的考虑都不应该直接开放给接入层（或者是调用者），引入网关层设计可以很好解决上述问题，并且可通过网关层实现特定需求，如黑名单过滤，鉴权、反向路由等。 接入层： 统一引入LB，可分为外部LB以及内部LB。负载均衡已成为标配，无论是需要充分利用资源，还是控制访问流量。主流的解决方式nginx、f5、软负载等。 方案价值 该方案中使用的基础数据库软件是一款拥有自主知识产权的国产数据库产品，其强一致性可以确保数据准确，减少患者和医疗提供者的不必要纠纷；该数据库软件拥有极高的处理性能，可以极大缩短患者排队缴费时长，建设电子票据平台，与业务系统无缝衔接，面向交款人提供多样化的票据交付渠道，为医院提供收费与票据数据自动核对机制，保障开票的准确性，与单位财务系统对接，为单位提供便利入账。 更多信息内容请移步星瑞格官方社区，期待大家加入 Sinoregal Tech Forum​编辑https://forum.sinoregal.cn/https://forum.sinoregal.cn/

#功能发布 长安链3.0正式版发布了多个重点功能，包括共识算法切换、支持java智能合约引擎、支持后量子密码、web3生态兼容等。我们接下来为大家详细介绍新功能的设计、应用与规划。 在《2022年度长安链开源社区开发者调研报告》中，对Java合约语言支持是开发者更为普遍的需求；《2023年中国开发者调研报告》显示，熟悉Java语言的开发者占到40%以上，尤其在传统行业应用中为应对使用区块链技术进行数字化转型的需求，支持java语言合约将使区块链技术更快的渗透到各行各业。 Docker Go上线以来，因其良好的可移植性，可扩展性和安全性获得较多使用，更因其支持使用原生的Go语言编写合约，有更好的易用性。 在企业客户的使用中Java语言的使用更为广泛，因此在长安链v3.0.0正式版中新增Docker Java合约引擎，支持使用原生Java语言编写合约。 1. 整体架构 Docker Java合约引擎的设计复用了Docker Go的架构。依然是采用抢占式任务调度和多个合约进程并发，单个合约进程串行执行交易的形式运行。更详细的设计可以参考长安链 VM Engine架构设计深度解读。 Docker Java 和 Docker Go 合约引擎互不冲突，可以同时启用。部署和连接方式如下图所示： 2. 编写Java合约 2.1 版本和工具 当前合约执行环境为JDK 11，推荐使用JDK 11编写合约；推荐使用 IDEA 或 Vscode等IDE编写和编译Java合约。 2.2 引用合约sdk 2.2.1 添加依赖包 在gradle项目中使用SDK 在build.gradle 中添加dependencies： implementation group:'org.chainmaker', name:'contracts-sdk-java', version:'1.0' 在Maven项目中使用SDK 在pom.xml 中添加dependencies： <dependency> <groupId>org.chainmaker</groupId> <artifactId>contracts-sdk-java</artifactId> <version>1.0</version> </dependency> 2.2.2 本地编译包 将项目引入到本地并编译安装到本地maven库： git clone -b v3.0.0 https://git.chainmaker.org.cn/chainmaker/contract-sdk-java.git cd contract-sdk-javamvn clean install '-Dmaven.test.skip=true' 然后通过添加依赖包引入到合约开发项目。 2.3 合约编写规则 2.3.1 合约必须实现接口 IContract 合约必须需要实现合约初始化方法（initContract） 和合约升级方法（upgradeContract）。

3月6日结束的2024年长安链技术路线规划直播中，由两位长安链架构师与社区开发者同步了接下来一年长安链主要的技术迭代规划与商业化支持策略。长安链2023年发布了2.3.x版本作为Lts版本，无论从功能、稳定性、性能和安全性上都更满足生产需求，又以大规模、高安全、广兼容、更易用为目标发布了开源功能版 v3.x。 2024年长安链将面向几个方向做更多工作：可用性、高性能、隐私性和开放性。 可用性 分级按需的同步模型。目前同步节点同步数据是全量数据同步，实际应用中很多业务场景中只需要同步一部分数据。长安链将数据从网络源头控制数据同步，也就是说部分数据同步的情况下即使是网络抓包也看不到全量数据，并且支持不完整数据下的区块验证。 源码安装支持。解决跨平台、跨架构的长安链安装问题。 多模块状态数据查询。目前有很多企业基于长安链做了BaaS等平台产品，支持存储、共识、VM等核心模块的当前状态查询可以增强平台的告警监控能力。 DockerJava合约大小优化。目前3.0版本中把用户用到的jar包都打包进去，jar包相对较大，后面考虑提前加载或帮用户编译的方式降低Docker Java合约大小。 自定义交易优先级。实际场景中用户有时候会希望交易优先上链。目前长安链交易分两种类型，配置类交易和普通交易（即正常的业务交易），配置类交易会优先上链，普通交易占大部分是按照先来先上链的顺序，后面计划增加自定义交易优先级的能力。 性能 长安链一直持续在做性能优化，目前计划有几点优化方向： 流水线模型。主要是针对长安链交易执行过程的调整，长安链的从节点在收到主节点的提案之后就会执行交易，我们发现把交易执行过程放到整个区块的共识之后性能会更高，这就要求我们处理随机函数类交易执行结果不一致的问题。 确定性调度算法。长安链目前主要是非确定性调度算法，一般是主节点把交易的调度DAG确定下来，从节点按照DAG模型支持，主节点和从节点是串行执行，后面增加确定性调度算法使主从串行执行模型调整为主从并行执行模型。 自研嵌入式存储引擎。实际的工作中我们发现，区块链和其他的使用数据库的系统有很大区别，对于区块链而言高度是非常重要的指标，我们利用高度的特点考虑自研区块链专用存储引擎。 Docker引擎优化机制。目前长安链Docker引擎为了处理死循环的问题采用进程的管理机制，实际上一个区块在一段时间内如果调用的合约非常多，就会出现进程启停的情况。我们将优化进程管理机制，尝试协程、线程模型，降低资源消耗，提高合约加载效率和执行性能。 支持Redis存储模型。Redis是市面上比较重要的KV存储模型，适合查询比较多的应用场景，我们将进行支持。 隐私性 敏感数据的隐藏。部分业务方希望上链的数据只有一部分相关方能看到，其他相关方看不到，或部分业务方只希望公开部分数据，针对此类需求我们正在考虑相关的支持方案。 数据落盘加密。目前长安链支持一部分数据落盘加密，后续将支持写入数据库的Value自动加密，从数据库获取后会自动解密。 私有数据集。和敏感数据隐藏有些类似，数据仅在共识时对指定可见方可见，在达成共识后不会存储。 开放性 开放性部分欢迎社区成员的积极参与，可以公众号后台或联系开源社区小助手。 Go合约本地调试。此功能将不需要单独起一条链调试，我们会提供一个模块，按照我们的模板在内部调试我们的合约。 异常注入功能。目前长安链为了安全性考虑已经开发了一套非嵌入式的异常自检机制，可以在不嵌入长安链代码的情况下检查是否有安全性上的异常，目前支持共识、交易池、核心引擎等多个模块。后续计划开源出来，支持外部开发者自定义异常注入，届时欢迎社区贡献。 Binlog数据分发。业务场景上的需求，例如部分业务方由于网络原因，没办法通过同步模块导入数据，会希望以文件的方式导入数据。 直播精彩问答 1、Q：2.0到3.0可以直接升级吗？什么时候3.0开始有LTS版本？ A：3.0以前的版本想要升级到2.3.0以后，需要先升级到2.3.0过渡。具体升级方案见：https://docs.chainmaker.org.cn/v3.0.0/html/instructions/%E7%89%88%E6%9C%AC%E5%8D%87%E7%BA%A7%E8%AF%B4%E6%98%8E.html。目前的v3.0.0就是LTS版本，后续也会支持平滑升级到v3.0.0的后续版本。 2、Q：3.0可以接入remix了，是不是意味着可以使用web3j的工具调用长安链了？ A：需要部署chainmaker-x-web3，就可以兼容现有web3生态。现在是使用一种全新的交易类型，以及交易处理流程来兼容web3生态工具，偏探索性质，建议用户先体验。 3、Q：共识算法动态切换是自发切换吗？ A：不是，需要用户发送共识算法切换的交易，达成共识后才会实际切换成功，建议网络比较稳定时操作，因为切换时会检查节点间的连接状态。 虽然不支持自发切换，但是用户可以自己在外部实现类似功能，例如检查到安全性比较高场合，性能较低时，可以将TBFT切换为RAFT。 4、Q：3.0交易优先级会有什么策略排优先级？ A：尚未完全确定，目前可想到的策略优先级主要包括以下几部分： 1） 按照合约来排序； 2） 按照组织来排序； 3） 用户在交易中自定义优先级； 另外也欢迎社区提供自己的建议。 5、Q：这种流水线模型是那种类似hotstuff的流水线共识吗？ A：类似，现有的长安链执行逻辑是这样的，首先主节点执行一批交易，形成一个提案，广播给从节点，从节点会按照主节点提案中的DAG执行交易，然后共识，最后达成一致。我们在实际测试中发现，如果将从节点执行交易这个流程移动到达成共识后，性能会更高，也就是说共识的仅仅是区块本身（没有执行结果），就会存在类似DockerGo这种合约会出现随机函数类交易的问题，所以方案就是会将这个执行结果伴随着下个区块的提案一起广播，这种处理非常类似于HotStuff的处理思路，所以我们称为流水线模型。 6、Q：兼容性这里比较复杂，需要怎么设计呢？比如执行有个bug，新版本修了，如何让新版本兼容同步老版本的区块执行结果？ A：在长安链中有两个版本号，一个是链版本号，一个是二进制版本号，链版本号指的是目前这条运行的链的版本号，它是写在数据库中的（配置文件），二进制版本号指的是在代码中写的这个二进制的版本号信息。在实际处理兼容性的时候，举个例子，假设在2.3.1发现了一个BUG，在232进行了修复，那么处理逻辑就是判断当前的链版本号是否是231，如果是231就走原逻辑，如果不是，则走新的逻辑。在升级时，需要等全网的所有节点全部替换二进制后，由用户发送一笔升级链配置的交易，实现逻辑处理的调整，在这笔交易生效之前，虽然二进制版本是2.3.2，但逻辑仍然是2.3.1的。 7、Q：Java SDK支不支持同态加密、分层加密等go实现的那些密码学算法？ A：支持分层加密，其他暂不支持。可借鉴分层加密引入的技术路线，自行实现。

零知识证明是区块链扩容和隐私保护的关键前沿技术，其天然具备完备性、可靠性和零知识性的特点，是提升区块链交易吞吐量与可扩展性、在验证用户身份的同时保护用户数据隐私，实现复杂计算不可或缺的关键技术。基于零知识证明技术实现高兼容性、高效率、可扩展的实用性zkEVM是业内持续研究的关键难题。 长安链团队面向上述难题开展zkEVM框架设计及其核心子电路构建技术攻关，近日该团队论文《Fast RS-IOP Multivariate Polynomial Commitments and Verifiable Secret Sharing》成功入选网络与信息安全领域国际顶级学术会议Usenix Security 2024。 论文所提出的高效多变量多项式承诺，是首个支持一对多且证明者复杂度最优的协议，对实现不同场景下的安全高效隐私计算具有重要意义。实验表明，论文所提出的多变量多项式承诺在保持验证时间和证明规模接近的情况下，比现有其他透明多项式承诺快5-10倍。所提出一对多多变量多项式承诺比现有（单变量）其他协议证明时间快2-4倍，验证时间快2-4倍。 多项式承诺可用于证明被承诺多项式某点取值的有效性。基于里德所罗门编码的多项式承诺具有无需可信建立、抗量子安全、运行效率高、通信和验证复杂度低的特点。一对多多项式承诺允许一个证明者高效地向多个验证者分别证明一个多项式上的多个点，可显著提升分布式密码系统中的基本原语，即异步可验证秘密分享的效率。然而，目前的一对多多项式承诺仅支持单变量多项式承诺而非多变量，无法直接应用于异步可验证秘密分享。此外，基于里德所罗门编码的多变量多项式承诺目前只能实现准线性级别的证明者计算复杂度。 面对这一棘手问题，研究团队提出了一种新的基于里德所罗门编码的多变量多项式承诺，独创rolling batch FRI技术降低多变量多项式承诺的证明者计算复杂度，达到了理论最优的线性级别；通过构造特殊求值点，设计了具有理论最优级别证明者复杂度的一对多变种方案，可应用于异步秘密分享并显著优化秘密分享中分发者的计算时间。 图 1 所提出多项式承诺PolyFRIM的复杂度比较 图 2 所提出多项式承诺PolyFRIM的实际性能比较 作为长安链zkEVM关键技术研究重要内容之一，该论文的核心算法将进一步拓展长安链对于构建用户通用化隐私计算的zkEVM的支持，以持续不断的技术创新提升长安链链下的扩容能力。长安链将汇集产学研用多方力量，从基础理论、工程实践到应用示范、产业协同多个角度推动区块链技术领原始创新与技术产业发展。