肝了三晚，终于吃透了Druid连接池
前言
作为一个java程序员，数据库的JDBC几乎每天都在做，数据库连接池Druid每天也在使用，但可能用起来太简单了(spring中引入依赖即可)，往往忽略了连接池的意义和优化
本文从源码的角度分析Druid的常用配置及原理
连接
当我们程序需要访问数据库时，需要创建一个本地到数据库服务的网络连接，此时本地代码就相当于一个数据库的客户端，可以通过这个连接去访问数据、执行sql，如下
Driver
数据结构与算法
ES-集群配置7.1.1
1、优化配置主机配置
cat << EOF >>/etc/security/limits.conf
root soft nofile 65535
root hard nofile 65535
* soft nofile 65536
* hard nofile 65536
EOF
echo "vm.max_map_count=655360">>/etc/sysct
⼤公司的分库分表都是怎么玩的？
当业务规模达到⼀定规模之后，像淘宝⽇订单量在5000万单以上，美团3000万单以上。数据库⾯对海量的数据压⼒，分库分表就是必须进⾏的操作了。⽽分库分表之后⼀些常规的查询可能都会产⽣问题，最常⻅的就是⽐如分⻚查询的问题。⼀般我们把分表的字段称作shardingkey，⽐如订单表按照⽤户ID作为shardingkey，那么如果查询条件中不带⽤户ID查询怎么做分⻚？⼜⽐如更多的多维度的查询都没有shar
订单中心架构设计与实践
不同的业务采用不同的系统架构，会有自己的一些特色架构难题。今天我们来学习下电商业务中的订单中心的架构设计，以及会遇到哪些技术挑战。
一、背景
随着用户量级的快速增长，vivo 官方商城 v1.0 的单体架构逐渐暴露出弊端：模块愈发臃肿、开发效率低下、性能出现瓶颈、系统维护困难。
从2017年开始启动的 v2.0 架构升级，基于业务模块进行垂直的系统物理拆分，拆分出来业务线各司其职，提供服务化的能力
469. 还是自主可控香
用别人开发的软件，阅读别人的代码，对于程序员来说，相比之下，终究还是没自己（包括加入的团队）开发的香。
自己开发的软件遇到什么错误，直接能通过现象，思维贯穿到底层去定位到问题，看到本质，跟火眼金睛似的。
别人开发的就不一样了，尤其是小众软件，遇到个问题，看到苍白的报错日志，只能说：“我勒个去”！
去年写了个分布式数据库一键部署脚本，实在是太香了，配置内存和节点IP，两个参数，就可以装一套分布式数据
docker-daemon.json配置详解
多个配置一定要加逗号，否则启动不成功，先给个例子：我修改了docker0的网络、信任私有镜像库、存储位置
vim /etc/docker/daemon.json
{
"bip": "0.0.0.0/0",
"insecure-registries" : ["registry.gag.cn"],
"data-root": /data/docker
}
[root@vm-1677489993 ~]
使用redis的bitmap实现签到功能
一、签到功能的实现思路
最常规的思路，一般我们会选择每个用户，每天的签到作为一条mysql表的数据，然后一条一条的记录。这种方式的确是可以的，但是它的局限性很大，只能适用于小规模公司的内部系统，人数不多的情况下。
如果是用于普通大众的话，这就将不堪设想。如果有一百万用户，每天签到，一个月，需要存的数据就会有三千万条数据，一年，需要存三亿六千万条数据。这要是用户量再大点，或者使用的时长再长点，这数据
数据变更注意事项 - 1 生产环境改表结构
1. pt-online-schema-change
官网:
新建一模—样的_new表
新表执行更改字段操作
原表上加三个触发器，DELETE/UPDATE/INSERT
原表的数据拷贝到新表中，然后替换掉原表
2. 安装
下载地址：
