分表后⾮sharding_key的查询怎么处理呢？
1. 可以做⼀个mapping表，⽐如这时候商家要查询订单列表怎么办呢？不带user_id查询的话你总不能扫全表吧？所以我们可以做⼀个映射关系表，保存商家和⽤户的关系，查询的时候先通过商家查询到⽤户列表，再通过user_id去查询。
2. 打宽表，⼀般⽽⾔，商户端对数据实时性要求并不是很⾼，⽐如查询订单列表，可以把订单表同步到离线（实时）数仓，再基于数仓去做成⼀张宽表，再基于其他如es提供查询服务
数据结构与算法
肝了三晚，终于吃透了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表的数据，然后一条一条的记录。这种方式的确是可以的，但是它的局限性很大，只能适用于小规模公司的内部系统，人数不多的情况下。
如果是用于普通大众的话，这就将不堪设想。如果有一百万用户，每天签到，一个月，需要存的数据就会有三千万条数据，一年，需要存三亿六千万条数据。这要是用户量再大点，或者使用的时长再长点，这数据
