怎么判断请求是正常请求还是被扫
看kibana上的网关日志，如果x_real_ip比较分散，或者referer的域名是系统域名，说明是正常请求
高并发场景下，查缓存为空，查库也为空，也要设置缓存，否则对于库内不存在的查询，会给db造成压力
开放平台的token，应区分app_access_token和user_access_token。
需要用户身份执行的操作，用user_access_token，其他操作用app_access_token。
比如飞书开放平台，创建飞书文档、发起审批这种操作，应该用user_access_token。
如果mq消费者执行的逻辑，与用户直接交互（比如给用户发通知），需要限制mq的重试次数，否则消费失败的话，mq不断重试，用户会受到很多次通知
点击按钮，打开新的浏览器窗口，chrome看不到请求信息，可以用wireshark等抓包工具
业务库跟报表库最好分开，因为两者对索引的需求存在矛盾，
业务库希望索引不要太多，因为修改、插入、删除比较多
报表库希望有更多索引，因为有大量查询操作
能不放在事务里面的最好不要放在事务里面。可以将常规的数据库查询操作放在事务前面进行，而事务内进行增、删、改、加锁查询等操作。
created_date、updated_date等字段不应该与业务逻辑有关，否则数调的时候，会有问题。
举个例子，把created_date字段作为新闻的发布日期，假如有一天，你发现昨天的新闻少了一篇，通过后台补录一篇文章，created_date是今天，就有问题了，实际的发布日期是昨天。
Major.Minor.Patch 的三位版本规则，其中Major表示大版本，通常是一些重大改变，因此彼此之间功能可能会不兼容；Minor表示小版本，通常是一些新功能的增加；最后Patch表示修订版，主要为修复一些重点Bug而发布的版本。例如：Kafka 2.1.1，大版本就是2，小版本是1，Patch版本为1，是为修复2.1.0版本的Bug发布的第1个版本。
为什么有些系统把业务逻辑写在oracle存储过程
1.对于比较复杂的业务逻辑，如果不用存储过程，需要查询多次db，需要多次建立、释放连接，如果用存储过程，就可以只用一次连接
2.存储过程只在创造时进行编译，以后每次执行存储过程都不需再重新编译，而一般SQL语句每执行一次就编译一次,所以使用存储过程可提高数据库执行速度
3.安全性高,可设定部分用户才具有对指定存储过程的使用权
4.对于一些查询十分耗时，且更新频率较低的数据，可以用oracle存储过程先跑出结果，把结果写入结果表，应用层直接从结果表读数据即可
5.oracle对存储过程的支持比mysql好很多，包括性能、语法
至于为什么存储过程在oracle很常见，在mysql少见，就转化为另一个问题：为什么mysql不推荐使用存储过程
现在之所以不推荐使用存储过程，一是因为数据库本身容易成为性能瓶颈，应尽量把业务逻辑上移到应用层；二是因为业务逻辑分散在应用层和数据库层，不方便维护
重定向与转发
转发：
地址栏不发生变化，显示的是上一个页面的地址
请求次数为1次
请求域中数据不会丢失
页面跳转在服务端进行
重定向：
地址栏显示新的地址
请求次数为2次
请求域中的数据会丢失，因为是2次请求
页面跳转在浏览器端进行
谨慎用while，如果要用，一定要排除导致死循环的可能。
尤其是多个变量共同决定while退出条件时，
比如while (left != right)这样的退出条件，需要考虑left和right始终不相等的情况。
开发app或浏览器的后端，有什么区别：
如果是浏览器，前后端代码可以同时迭代，可以不用考虑接口兼容
如果是app，如果不强制要求用户更新app，就需要做接口兼容
逻辑删除字段容易导致有些sql不走索引，影响性能
与其他系统同步数据时，要协调好各自的数据库表字段长度，避免超过长度限制
反爬经验
url上插入一些无效字符串，让爬虫者不知道这些字符串怎么来的
把数据通过html格式返回给前端，而不是json格式
电商的业务流程，应先走完购买流程，再扣库存。
如果先扣库存，再走购买流程，如果购买流程异常而且事务回滚也异常，库存数量就有问题。
网友评论