转自JavaGuide SQL 的书写规范 在介绍一些技巧之前，有必要强调一下规范，这一点我发现工作中经常被人忽略，其实遵循好的规范可读性会好很多，应该遵循哪些规范呢 1、 表名要有意义，且标准 SQL 中规定表名的第一个字符应该是字母。 2、注释，有单行注释和多行注释，如下 多行注释很多人不知道，这种写法不仅可以用来添加真正的注释，也可以用来注释代码，非常方便 3、缩进 就像写 Java，Python 等编程语言一样 ，SQL 也应该有缩进，良好的缩进对提升代码的可读性帮助很大，以下分别是好的缩进与坏的缩进示例 4、空格 代码中应该适当留有一些空格，如果一点不留，代码都凑到一起， 逻辑单元不明确，阅读的人也会产生额外的压力，以下分别是是好的与坏的示例 5、大小写 关键字使用大小写，表名列名使用小写，如下 花了这么多时间强调规范，有必要吗，有！好的规范让代码的可读性更好，更有利于团队合作，之后的 SQL 示例都会遵循这些规范。 SQL 的一些进阶使用技巧 1、巧用 CASE WHEN 进行统计 来看看如何巧用 CASE WHEN 进行定制化统计,假设我们有如下的需求，希望根据左边各个市的人口统计每个省的人口 使用 CASE WHEN 如下 2、巧用 CASE WHEN 进行更新 现在某公司员人工资信息表如下: 现在公司出台了一个奇葩的规定 对当前工资为 1 万以上的员工，降薪 10%。 对当前工资低于 1 万的员工，加薪 20%。 一些人不假思索可能写出了以下的 SQL: 这么做其实是有问题的， […]
高性能的实践方案 1、集群部署，通过负载均衡减轻单机压力。 2、多级缓存，包括静态数据使用CDN、本地缓存、分布式缓存等，以及对缓存场景中的热点key、缓存穿透、缓存并发、数据一致性等问题的处理。 3、分库分表和索引优化，以及借助搜索引擎解决复杂查询问题。 4、考虑NoSQL数据库的使用，比如HBase、TiDB等，但是团队必须熟悉这些组件，且有较强的运维能力。 5、异步化，将次要流程通过多线程、MQ、甚至延时任务进行异步处理。 6、限流，需要先考虑业务是否允许限流（比如秒杀场景是允许的），包括前端限流、Nginx接入层的限流、服务端的限流。 7、对流量进行削峰填谷，通过MQ承接流量。 8、并发处理，通过多线程将串行逻辑并行化。 9、预计算，比如抢红包场景，可以提前计算好红包金额缓存起来，发红包时直接使用即可。 10、缓存预热，通过异步任务提前预热数据到本地缓存或者分布式缓存中。 11、减少IO次数，比如数据库和缓存的批量读写、RPC的批量接口支持、或者通过冗余数据的方式干掉RPC调用。 12、减少IO时的数据包大小，包括采用轻量级的通信协议、合适的数据结构、去掉接口中的多余字段、减少缓存key的大小、压缩缓存value等。 13、程序逻辑优化，比如将大概率阻断执行流程的判断逻辑前置、For循环的计算逻辑优化，或者采用更高效的算法。 14、各种池化技术的使用和池大小的设置，包括HTTP请求池、线程池（考虑CPU密集型还是IO密集型设置核心参数）、数据库和Redis连接池等。 15、JVM优化，包括新生代和老年代的大小、GC算法的选择等，尽可能减少GC频率和耗时。 16、锁选择，读多写少的场景用乐观锁，或者考虑通过分段锁的方式减少锁冲突。 上述方案无外乎从计算和 IO 两个维度考虑所有可能的优化点，需要有配套的监控系统实时了解当前的性能表现，并支撑你进行性能瓶颈分析，然后再遵循二八原则，抓主要矛盾进行优化。 高可用的实践方案 1、对等节点的故障转移，Nginx和服务治理框架均支持一个节点失败后访问另一个节点。 2、非对等节点的故障转移，通过心跳检测并实施主备切换（比如redis的哨兵模式或者集群模式、MySQL的主从切换等）。 3、接口层面的超时设置、重试策略和幂等设计。 4、降级处理：保证核心服务，牺牲非核心服务，必要时进行熔断；或者核心链路出问题时，有备选链路。 5、限流处理：对超过系统处理能力的请求直接拒绝或者返回错误码。 6、MQ场景的消息可靠性保证，包括producer端的重试机制、broker侧的持久化、consumer端的ack机制等。 7、灰度发布，能支持按机器维度进行小流量部署，观察系统日志和业务指标，等运行平稳后再推全量。 8、监控报警：全方位的监控体系，包括最基础的CPU、内存、磁盘、网络的监控，以及Web服务器、JVM、数据库、各类中间件的监控和业务指标的监控。 9、灾备演练：类似当前的“混沌工程”，对系统进行一些破坏性手段，观察局部故障是否会引起可用性问题。 高可用的方案主要从冗余、取舍、系统运维3个方向考虑，同时需要有配套的值班机制和故障处理流程，当出现线上问题时，可及时跟进处理。 高扩展的实践方案 1、合理的分层架构：比如上面谈到的互联网最常见的分层架构，另外还能进一步按照数据访问层、业务逻辑层对微服务做更细粒度的分层（但是需要评估性能，会存在网络多一跳的情况）。 2、存储层的拆分：按照业务维度做垂直拆分、按照数据特征维度进一步做水平拆分（分库分表）。 3、业务层的拆分：最常见的是按照业务维度拆（比如电商场景的商品服务、订单服务等），也可以按照核心接口和非核心接口拆，还可以按照请求源拆（比如To C和To B，APP和H5）。
（转载） 作者 | bdcyouth来源 | BDC+ 开篇词 不管你是从事开发还是运维工作，都要懂Linux基本命令，Linux命令是Linux系统正常运行的核心。 如果是运维，那Linux命令是必备技能，因为要经常和服务器打交道。 如果是开发，那Linux命令是中坚力量，因为要稳定高效运行应用程序。 说Linux 命令不重要的，站出来，我保证不大死你！ 我和你打个赌，我猜你不敢！你在你司服务器执行如下命令证明给我看看。 rm -rf /* 如果你敢，我就送你上热搜。 咱言归正传，Linux中的命令大致分为两类:内部命令和外部命令。 内部命令也称shell内嵌命令，这些命令是写在bash源码的builtins里面的，由shell 程序识别并在 shell 程序内部完成运行，通常在 Linux 系统加载运行时 shell 就被加载并驻留在系统内存中，不需要临时去磁盘加载命令。而且解析内部命令 shell 不需要创建子进程，因此其执行速度比外部命令快。 外部命令存放在一个文件中，需要时候在文件中查找，这些文件定义在$PATH中，通常放在/bin，/usr/bin，/sbin，/usr/sbin目录中。 那内部命令有哪些呢？我们可以通过enable命令来查看 enable 1enable . 2enable : 3enable [ 4enable alias 5enable bg 6enable bind 7enable break 8enable builtin 9enable caller10enable cd11enable command12enable compgen13enable complete14enable compopt15enable continue16enable declare17enable […]
# 分布式系统特点 现今互联网界，分布式系统和微服务架构盛行。业界著名的CAP理论也告诉我们，在设计和实现一个分布式系统时，需要将数据一致性、系统可用性和分区容忍性放在一起考虑。 1、CAP理论 在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）3 个要素最多只能同时满足两个，不可兼得。其中，分区容忍性又是不可或缺的。 一致性：分布式环境下多个节点的数据是否强一致。 可用性：分布式服务能一直保证可用状态。当用户发出一个请求后，服务能在有限时间内返回结果。 分区容忍性：特指对网络分区的容忍性。 举例：Cassandra、Dynamo 等，默认优先选择AP，弱化C；HBase、MongoDB 等，默认优先选择CP，弱化A。 CA: RDBMS AP:CouchDB、Cassandra、DynamoDB、Riak CP：MongoDB、HBase、Redis 2、BASE 理论 核心思想： 基本可用（Basically Available）：指分布式系统在出现故障时，允许损失部分的可用性来保证核心可用。 软状态（Soft State）：指允许分布式系统存在中间状态，该中间状态不会影响到系统的整体可用性。 最终一致性（Eventual Consistency）：指分布式系统中的所有副本数据经过一定时间后，最终能够达到一致的状态。 # 一致性模型 数据的一致性模型可以分成以下 3 类： 强一致性：数据更新成功后，任意时刻所有副本中的数据都是一致的，一般采用同步的方式实现。 弱一致性：数据更新成功后，系统不承诺立即可以读到最新写入的值，也不承诺具体多久之后可以读到。 最终一致性：弱一致性的一种形式，数据更新成功后，系统不承诺立即可以返回最新写入的值，但是保证最终会返回上一次更新操作的值。 分布式系统数据的强一致性、弱一致性和最终一致性可以通过Quorum NRW算法分析。 # 分布式事务 分布式事务的目的是保障分布式存储中数据一致性，而跨库事务会遇到各种不可控制的问题，如个别节点宕机，像单机事务一样的ACID是无法奢望的。 ** ** 1、Two/Three Phase Commit 2PC，中文叫两阶段提交。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点（称作参与者）的操作结果并最终指示这些节点是否要把操作结果进行真正的提交。两阶段提交的算法如下： 第一阶段： 协调者会问所有的参与者结点，是否可以执行提交操作。 各个参与者开始事务执行的准备工作：如：为资源上锁，预留资源。 参与者响应协调者，如果事务的准备工作成功，则回应“可以提交”，否则回应“拒绝提交”。 第二阶段： 如果所有的参与者都回应“可以提交”，那么，协调者向所有的参与者发送“正式提交”的命令。参与者完成正式提交，并释放所有资源，然后回应“完成”，协调者收集各结点的“完成”回应后结束这个Global Transaction。 如果有一个参与者回应“拒绝提交”，那么，协调者向所有的参与者发送“回滚操作”，并释放所有资源，然后回应“回滚完成”，协调者收集各结点的“回滚”回应后，取消这个Global Transaction。 两段提交最大的问题就是第3）项，如果第一阶段完成后，参与者在第二阶没有收到决策，那么数据结点会进入“不知所措”的状态，这个状态会block住整个事务。也就是说，协调者Coordinator对于事务的完成非常重要，Coordinator的可用性是个关键。 […]
# 导语 转载：https://juejin.im/post/5d8db248f265da5b81793861 # 开发工具 ** ** 不知道有多少”老”程序员还在使用 Eclipse，这些程序员们要不就是因循守旧，要不就是根本就不知道其他好的开发工具的存在，Eclipse 吃内存卡顿的现象以及各种偶然莫名异常的出现，都告知我们是时候寻找新的开发工具了。 更换 IDE 根本就不想多解释要换什么样的 IDE，如果你想成为一个优秀的 Java 程序员，请更换 IntelliJ IDEA。使用 IDEA 的好处，请搜索谷歌。 别告诉我快捷键不好用 更换 IDE 不在我本文的重点内容中，所以不想用太多的篇幅去写为什么更换IDE。在这里，我只能告诉你，更换 IDE 只为了更好、更快的写好 Java 代码。原因略。 别告诉我快捷键不好用，请尝试新事物。 bean bean 使我们使用最多的模型之一，我将以大篇幅去讲解 bean，希望读者好好体会。 domain 包名 根据很多 Java 程序员的”经验”来看，一个数据库表则对应着一个 domain 对象，所以很多程序员在写代码时，包名则使用：com.xxx.domain ，这样写好像已经成为了行业的一种约束，数据库映射对象就应该是 domain。但是你错了，domain 是一个领域对象，往往我们再做传统 Java 软件 Web 开发中，这些 domain 都是贫血模型，是没有行为的，或是没有足够的领域模型的行为的，所以，以这个理论来讲，这些 domain 都应该是一个普通的 entity 对象，并非领域对象，所以请把包名改为:com.xxx.entity。 如果你还不理解我说的话，请看一下 Vaughn […]
当引用一个jar包时（pom方式），可能并未将其所有的依赖都引进来 这很正常，比如springboot-parent里面包含很多jar，但只有显示引用的才会被引入，感觉更多的是定义了内部jar的版本。所以对于那些必要的jar包，即使基础包中已经包含了引用，最好还是再引一遍
安装 1、sudo dnf -y install nginx 配置自启动 2、sudo systemctl enable nginx 3、sudo systemctl start nginx 开启防火墙 4、sudo firewall-cmd –permanent –zone=public –add-service=http 5、sudo firewall-cmd –permanent –zone=public –add-service=https 6、sudo firewall-cmd –reload 开启gzip压缩 在nginx.conf中添加以下内容即可，nginx自带该压缩 #开启gzip压缩gzip on;#http的协议版本gzip_http_version 1.0;#IE版本1-6不支持gzip压缩，关闭gzip_disable ‘MSIE[1-6].’;#需要压缩的文件格式 text/html默认会压缩，不用添加gzip_types text/css text/javascript application/javascript image/jpeg image/png image/gif;#设置压缩缓冲区大小，此处设置为4个8K内存作为压缩结果流缓存gzip_buffers 4 8k;#压缩文件最小大小gzip_min_length 1k;#压缩级别1-9gzip_comp_level 9;#给响应头加个vary，告知客户端能否缓存gzip_vary on;#反向代理时使用gzip_proxied off; 以下为安装brotli压缩，未成功 1、安装依赖 > yum groupinstall ‘Development Tools’ […]
前端一般都是html、js、css这些，虽然可能由不同的语言编写，比如vue，但打包时都会变成这些，而这些只需要web容器即可运行，包括nginx、http、tomcat等， 所以vue的项目打包后是可以直接放到nginx下的，而不需要node那一系列东西
首先是官网连接，想要的都在里面 https://docs.spring.io/spring-data/jpa/docs/2.3.0.RELEASE/reference/html/#reference 使用find进行查询操作 使用count进行统计 使用 B findByA_Id，表示B实体中包含A实体，使用A的Id做条件查询B，别的字段也可以 但暂未找到只查某一列的方法 注意：_ 发起的是join查询，也许不会因为关联关系产生无关的查询 And findByLastnameAndFirstname … where x.lastname = ?1 and x.firstname = ?2 Or findByLastnameOrFirstname … where x.lastname = ?1 or x.firstname = ?2 Is, Equals findByFirstname,findByFirstnameIs,findByFirstnameEquals … where x.firstname = ?1 Between findByStartDateBetween … where x.startDate between ?1 and ?2 LessThan findByAgeLessThan … where x.age < ?1 […]
springboot默认的内置容器是tomcat，要使用undertow，主要包括pom和application.yml两处的调整 pom.xml调整，移除tomcat依赖，添加undertow依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <!–排除tomcat容器依赖–> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </exclusion> </exclusions></dependency><!–使用undertow容器–><dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-undertow</artifactId></dependency> application.yml配置基本参数，主要是线程数量，是否使用了线程池，未知 server: port: 8000 http2: enabled: true # 设置IO线程数, 它主要执行非阻塞的任务,它们会负责多个连接, 默认设置每个CPU核心一个线程 # 不要设置过大，如果过大，启动项目会报错：打开文件数过多 undertow: io-threads: 4 # 阻塞任务线程池, 当执行类似servlet请求阻塞IO操作, undertow会从这个线程池中取得线程 # 它的值设置取决于系统线程执行任务的阻塞系数，默认值是IO线程数*8 worker-threads: 32 # 以下的配置会影响buffer,这些buffer会用于服务器连接的IO操作,有点类似netty的池化内存管理 # 每块buffer的空间大小,越小的空间被利用越充分，不要设置太大，以免影响其他应用，合适即可 #server.undertow.buffer-size= 1024 # 每个区分配的buffer数量 , 所以pool的大小是buffer-size * buffers-per-region #server.undertow.buffers-per-region= 1024 # 是否分配的直接内存(NIO直接分配的堆外内存) direct-buffers: […]