二:
高并发下的数据安全
多线程写入同一个文件的时候, 会出现 "线程安全问题". 高并发的数据安全就是这个道理. 比如有可能会出现超发.
方案:
悲观锁思路: 修改数据时, 锁定状态, 排斥外部请求的修改.
缺点:
高并发下某些线程可能永远都抢不到这个 "锁", 请求就会死在那里. 堆积到一定程度, 连接数被耗尽, 系统异常.
FIFO 队列思路: 请求都排好队, 不会导致某些请求永远拿不到锁.
缺点:
高并发可能导致队列内存 "撑爆", 如果设置一个极大的内存队列, 系统处理请求的速度根本跟不上不断快速涌入的请求. 越积 越多, 还是会导致响应变慢, 系统陷入异常.
乐观锁思路:
跟悲观锁相比, 乐观锁都有资格去执行请求, 但会获得一个版本号, 符合版本号的才算更新成功.
缺点:
加大计算机 CPU 计算的开销, 但是这是一个比较好的解决方案.
缓存服务器思路:
Redis 分布式要保证数据都能能够平均的缓存到每一台机器, 首先想到的做法是对数据进行分片, 因为 Redis 是 key-value 存储的, 首先想到的是 Hash 分片, 可能的做法是对 key 进行哈希运算, 得到一 个 long 值对分布式的数量取模会得到一个一个对应数据库的一 个映射, 没有读取就可以定位到这台数据库
三:
高并发下的水分与查杀.
原因: 秒杀或是抢购等海量请求有时候并不是真正的用户在发送请求, 有些为了 "抢" 到商品会使用一些 "刷票" 等类似的工具. 这种做 法是帮助他们发送更多的请求到服务器. 更高级的还制作一些自动请求 脚本. 这些做法都是使自己的请求数占比多, 成功率高.
这些很显然都是属于作弊行为, 不过, 我们也有一些解决方案.
答: 分为以下几种情况
1, 同一个账号, 一次性发送多个请求.
高并发有可能会导致跳过某些逻辑判断.
方案: 程序入口处, 一个用户只允许一次请求, 其他过滤. 可以通过 Redis 内存缓存服务, 写入一个标志位 (只允许一个请求成功 , 结合 watch 乐观锁的特性)
2, 多个账号, 一次性发送多个请求
很多早期注册功能没有限制, 导致一些特殊的工作室通过编写自动注册脚本注册一大批 "僵尸账号". 专门做各种刷的行为, 以 及一些转发抽奖活动, 大大提升自己中奖的概率.
方案: 检测指定机器 IP 请求频率, 如果一个 IP 的请求频率异常的高. 给它弹出一个验证码或者禁止它的请求.
3, 多个账号, 不同 IP 发送不同请求
有一些机构自己独占一批 IP, 然后做成一个随机代理 IP 的服务, 有偿提供给这些 "工作室" 使用. 还有一些直接黑掉用户电脑, 转发 IP 包, 使普通用户的电脑变成 IP 代理出口.
方案: 难以分辨了, 容易 "误伤". 可以通过高门槛的业务, 或者通过 "数据挖掘" 来提前清理.
来源: http://www.bubuko.com/infodetail-3076514.html