2L 是一个很大的容量。参考一下，大瓶可乐 2.2-2.5L ，电热水壶 1.5-1.8L ，经典超大个的子弹保温壶不到 1L 。2L 这么大的容量，不带烧水功能的纯水壶都不一定有，不保温的更难找。

水壶也没啥特殊材质要求，要心理安慰的话也就不锈钢和玻璃。但是不锈钢铁定保温，并且限于不锈钢自身重量，很少做大，超过 800ML 都难。玻璃因为容易摔也很少做大，勉强能上 1L 。要想弄大的，一般只能是塑料材质的，即俗称的太空杯。这个随便买就行，想买贵得就找乐扣。

即时是凉开水，喝多了照样对肠胃不好，建议还是直接上恒温壶。

可以先写个脚本，用 GaussDB 的原生连接方式，高并发的去 select 'x' ，比较一下用 PG JDBC 驱动连接方式高并发 select 'x' 的情况。如果一样，那就只是数据库的问题，交给华为去处理。如果明显不一样，那就很有可能是 JDBC 驱动的问题，还是交给华为去处理，因为 JDBC 驱动是数据库厂商负责的。

具体情况不是很了解。但并发量起来后才变慢、变慢但是最终会完成、跟踪到执行 SQL 阶段慢的背景，看起来很像是数据库单点阻塞，应该先从数据库那里找问题。此外，这里是用 PG 的 JDBC 驱动去连接 PG 的衍生数据库，JDBC 驱动兼容性上也可能有问题。

取决于人数。一个人的话，非但不省钱，还会长胖。此外，人数越少，越容易造成单一饮食带来的营养不均衡。

人家打得就是打一枪换一个地方，能骗一个是一个的套路。发帖避雷或者封号什么的，屁用没有。楼主这种对网络上不认识的人，认爹认朋友的行为，才是应该拿来避雷的。

一般的权限管理组件只管到 URL 资源这一级别，不会往下再管，而你这个是业务逻辑权限，需要下层代码手动处理，或者更高级/复杂的权限管理组件。

拖发工资更多的是对公司士气和外部经营的影响，但你要走到法律责任的时候，比芝麻粒还小——拖发几个月最后只要补上就行，连滞纳金都没有。所以，这才刚开始就让签字的，那是准备直接不发了，你确实提年假了。

最优解就是硬刚拿第二批裁员补偿。一般情况下，磨洋工白拿工资吧。关键点有两个：一，你不需要明确拒绝，但一定不要签下同意，并且灰色福利该不要就不要——比如迟到了就让扣钱不要补灰色卡；二，一旦工资没有按时发放，那么就该转变成即时止损策略了。

@bler #9 a 、b 两个是直连的，他们不经过公网上其他地方的中转。

通过端口转发等措施，即使是内网机器，也可以在公网上开放端口。这个开放的不是完整 IP ，而是一个 IP 加特定端口，但 TCP 连接有端口就够了。NAT 网络中，不管是 BT 下载，还是电驴下载，还是点对点聊天，开启 UPnP 是必要条件。

不过 UPnP 或者其他端口转发措施，是网关/路由器提供的，家里的路由器可以自己开，运营商那里的网关是铁定不会开的，所以一旦运营商给的就是内网 IP 那就直接歇菜了。但是，TCP 连接只需要被叫端在公网就可以连得起来，故 a 、b 两个只要有一个在公网有端口，就可以连得上。这在 BT 下载的表现上是：如果你在内网，那么能看到很多主机，但是只能连接其中在公网上的；如果你在公网，那么你看到多少主机就能连接到多少主机。这个在非服务器建主的对战游戏中也有表现：如果你在内网，那么你只能进别人的主机，你建的主机别人进不了。

首先纠正一点，UDP 是不需要回复确认，不是不需要建立连接，可以认为它是单向连接。UDP 因为是单向连接，如果双方要相互沟通数据那么双方都得在公网上，这点反而不如 TCP 。

补上 2 点，就是 BT 下载的方式。
1 ，a 、b 跟 tracker 之间，只会沟通用户 a 、用户 b 的信息，不会传递真正的数据文件。跟 traker 之间的沟通，UDP 、TCP 皆可，不过如果是正常网络那么 TCP 就很浪费。
2 ，a 、b 各自从 traker 获取到对方的信息之后，a 、b 之间就抛开 tracker 直接建立 TCP 连接，然后相互传递文件数据了。a 、b 之间，最少有一个要有公网端口（ NAT 出来的端口也行），否则是无法建立 TCP 连接的。

同源策略是浏览器端的安全控制措施，不是服务器端的，你反代个毛蛋。

划重点：「 B 站，咸鱼等 app 」

不得不提一下，月薪请假，不管按照 21.75 ，还是 22 天计算扣钱，都有坑。比如 10 月请假 19 天，即实际上 10 月一天都没上班，公司照样得发 3 天的工资。这个坑只要过年放假员工多请几天假就会爆出来。正确的做法，应该是：如果出勤天数大于 11 ，那么工资就是{月薪} - {月薪/21.75} * 缺勤天数；如果出勤天数小于 11 ，那么工资就是 {月薪/21.75} * 出勤天数。这个 11 取得是 21.75 的一半，可以按照实际情况去换。

月薪请假，还有一种计算方式是，按照 {月薪} - {月薪/当月应出勤天数} * 缺勤天数，即{月薪/当月应出勤天数} * 出勤天数的计算方式。看起来很公平，但实际上更坑。财务做预算骂娘还是小事。员工 10 、1 、2 月不请假但也不出活，7 、8 月期间该忙的时候疯狂请假，这才是大问题。

@Sting #73
@poorcai #75

楼主的算法，就是日薪 363.6+按照出勤天数计算，但同时又期望了保姆长期干。哪天楼主来兴趣了请假一个月自己带娃，保姆就直接一个月零收入并且还不能另找超过一个月的其他工作（当然实际上保姆会直接不干）。