religioser_个人页

mongdb 可以实现更加复杂的value 类型；并且可以保持行内的事务； 可以去看redis 和 mongodb 的对比文章，都讲得比较透彻了；

无所谓6，7， 大部分linux 的基础命令都是想通的，学一些基础的即可；除非公司里明确要求要用哪一种；

有必要，可以支持一些简单的事务，用于实现乐观锁；
比如多线程并发修改一个key，可以实现类似锁争抢的设计；

学linux吧， linux 常有用，而爬虫不常有用；

先学java 吧，先学了python,后面再学java ，还是会比较吃力； 反之则容易些；

一般string 被final 修饰是放在方法的形参里的， 首先string 是不可变的，加final 是为了了从静态检查上，不允许重复给一个string 变量赋值，这种做法是推荐使用的，可以参见erlang 中，所有的变量都是final 的，可以让代码更加已读，每次如果需要用一个新的值，重新申请一个新的变量即可。否则一个变量被反复赋值，代码可读性很差。

如果没有续费，那么首先会自动过期锁定，数据会保留7天，7日内再续费，数据还在；过了7天，那么数据就被删除了；

推荐你到 《极客时间》上看 《从0开始学架构》，初步建立起架构设计的知识体系； 其次是面对业务努力去实践，编写技术方案，比如除了考虑功能性设计外，考虑负载均衡，可扩展性，容错性，如何分层设计，系统可测试性，性能容量设计，宕机后如何故障恢复，任何节点间网络故障后如何恢复等等，想的越全，越有体系，那么水平自然就高了；

在有了一定 java 基础后，可以看 Java Conccurent Document, 另外可以看《Java 并发编程实战》，这本书讲得是非常清楚的；

学习并发包源码及逐个写一些Demo也是不错的一个选择；

所谓web会话保持，是说本身一般http服务器是短连接请求的，前一次请求和后一次请求没有上下文关联，所有的数据都必须包含在每次的请求参数或者body里。那么会话保持无非是有地方保存一些公共的信息，那么每次请求时，服务器自动知道当前的上下文信息，一般简单做法是把session 信息保存在单独的缓存服务器如Redis中，另外的做法是使用slb 负载均衡能力，如session 黏连，让相同来源ip的请求都路由到相同的后端server。但是后者的做法有缺点，当后端一台服务器宕机后，用户请求的session信息就丢失了，用户会受损，甚至业务受到影响；

大规模并发服务器只是众多衡量服务器性能指标中的一项，10w并发，除了看数量外，更多的要看每个并发请求背后执行了什么？ 如何业务少，一台普通32c128G服务器即可，甚至更少；

搜索引擎对一批数据按某些字段倒排索引后，排序后列出topN 的过程；而AI 的范围要广泛得多，如机器学习，聚类算法等等。

1, disruptor 无锁数据结构，用在需要管理线程安全的队列等数据结构处，可以替换线程安全的blockingQueue等，但是它的使用比较苛刻；比如要求每一个item都要按指定大小对齐等；
正常业务很少会用到，一些高并发的中间件产品可以使用；

这个是连接自动重试功能，会持续从连接池获取连接，出现这个错误不是正常情况，是说明已经有问题了；
这个没办法从配置上修改的，并且也不建议修改；

可以先观察下现在网站服务器的流量曲线，尤其是峰值状态；不同访问量差异是较大的，另外静态的jpg ，js ，css 都可以通过CDN 服务来减少后端WEB服务器的访问；

k8s 虽然已经有了 状态服务的 维护，开发operator 管理也是比较复杂的，建议直接购买RDS 服务，降低运维负担，且实例有SLA 保障；

如果不涉及乐观锁，那么可以先查出
a.season = 'HO19'
and a.version_code = '2'
条件的a.gu_id 结果后，再到inv_dap_detail 中带入查询；

单字段过大频繁更新会增加binlog 日志量，加重服务器负担；
1，可以把大字段拆分出单独的表，平时如果频繁更新的不是大字段本身，这种做法可有效降低服务器负载及Binlog 增长速度；
2，大字段如果频繁更新，可以考虑使用Mongodb 文档存储等其他存储；mysql 不太适合这种场景；

网络上建议使用的是 VPC专有网络， 公网不建议使用的；

高可用版是 主备结构的，保证单点故障时候的高可用；
账号数量上限500个，不开放备库连接；因为备库是作为热备的，如果备库压力过大会影响主库故障时的故障恢复；