本人从事网路安全工作12年，曾在2个大厂工作过，安全服务、售后服务、售前、攻防比赛、安全讲师、销售经理等职位都做过，对这个行业了解比较全面。
最近遍览了各种网络安全类的文章，内容参差不齐，其中不伐有大佬倾力教学，也有各种不良机构浑水摸鱼，在收到几条私信，发现大家对一套完整的系统的网络安全从学习路线到学习资料，甚至是工具有着不小的需求。
最后，我将这部分内容融会贯通成了一套282G的网络安全资料包，所有类目条理清晰，知识点层层递进，需要的小伙伴可以点击下方小卡片领取哦！下面就开始进入正题，如何从一个萌新一步一步进入网络安全行业。
学习路线图
其中最为瞩目也是最为基础的就是网络安全学习路线图，这里我给大家分享一份打磨了3个月，已经更新到4.0版本的网络安全学习路线图。
相比起繁琐的文字，还是生动的视频教程更加适合零基础的同学们学习，这里也是整理了一份与上述学习路线一一对应的网络安全视频教程。
网络安全工具箱
当然，当你入门之后，仅仅是视频教程已经不能满足你的需求了，你肯定需要学习各种工具的使用以及大量的实战项目，这里也分享一份我自己整理的网络安全入门工具以及使用教程和实战。
项目实战
最后就是项目实战，这里带来的是SRC资料&HW资料，毕竟实战是检验真理的唯一标准嘛~
面试题
归根结底，我们的最终目的都是为了就业，所以这份结合了多位朋友的亲身经验打磨的面试题合集你绝对不能错过！
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
**2. 防止重复提交：**提交后按钮disabled，防止用户重复提交
**3. 商品详情页面：**使用Nginx+Lua+OpenResty实现商品详情页面的优化（需要掌握lua语言，不在本文讨论范围内）
二. 后端优化
1. 基于乐观锁/redis锁，防止库存超卖
这里拿乐观锁举例，redis锁原理都是一样的
① 不加版本号的行级悲观锁（多个用户操作一个商品，线程本身就是安全的，因为数据库默认开启行级锁）
@Update("update goods_table set inventory=inventory-1 where inventory > 0 and goods_id=#{goodsId}")
int inventoryDeduction(@Param("goodsId") Long goodsId);
② 带版本号的乐观锁（数据库需单独新增一个version字段，每次调接口，version加1）
@Select("SELECT order_id,goods_name,inventory,create_time,version from gooods_table where goods_id=#{goodsId}")
GoodsDto getByGoodsId(@Param("goodsId")Long goodsId);
@Update("update goods_table set inventory=inventory-1,version=version+1 where inventory > 0 and goods_id=#{goodsId} and version=#{version}")
int inventoryDeduction(@Param("goodsId")Long goodsId,@Param("version")Long version);
@Transactional
public BaseResponse<JSONObject> spike(String phone, Long GoodsId) {
GoodsDto goodsDto = seckillMapper.getByGoodsId(GoodsId);
if (goodsDto == null) {
return setResultError("商品信息不存在!");
}
Long version = goodsDto.getVersion();// 先获取版本号
int row = seckillMapper.inventoryDeduction(GoodsId, version);// 减库存
// 后续可以生成订单到订单表。。。
}
使用Jmeter工具压测一下，库存初始化100，模拟200个请求，结论是无论如何都不会出现库存为0的现象（超卖）
但方式①，200个请求，会有100个抢购成功，剩余库存为0，方式②，200个请求只有66个请求成功，剩余库存为34。
实际开发中也可以使用redis锁进行控制，详细参考博主之前的博客！
2. 基于Redis对用户实现频率限制（限流一般都会在网关做）
为了防止某个客户端一直刷下单接口，可以基于redis的setNx命令，实现抢购时用户的频率限制：
@Transactional
public BaseResponse<JSONObject> spike(String phone, Long GoodsId) {
GoodsDto goodsDto = seckillMapper.getByGoodsId(GoodsId);
if (goodsDto == null) {
return setResultError("商品信息不存在!");
}
// 用户频率限制 setnx 如果key存在话
Boolean reusltNx = redisUtil.setNx(phone, seckillId + "", 10l);
if (!reusltNx) {
return setResultError("访问次数过多，10秒后再实现重试!");// 直接return，无需执行下面的version++操作
}
Long version = goodsDto.getVersion();// 先获取版本号
int row = seckillMapper.inventoryDeduction(GoodsId, version);// 减库存
// 后续可以生成订单到订单表。。。
}
@Component
public class RedisUtil {
@Autowired
private StringRedisTemplate stringRedisTemplate;
// 如果key存在的话返回fasle 不存在的话返回true（原生redis的setNx命令会返回0或1）
public Boolean setNx(String key, String value, Long timeout) {
Boolean setIfAbsent = stringRedisTemplate.opsForValue().setIfAbsent(key, value);
if (timeout != null) {
stringRedisTemplate.expire(key, timeout, TimeUnit.SECONDS);
}
return setIfAbsent;
}
public void setList(String key, List<String> listToken) {
stringRedisTemplate.opsForList().leftPushAll(key, listToken);
}
}
3. 基于库存令牌桶 + MQ 实现异步修改库存并提交订单
在高并发情况下，如果有1万个用户同时秒杀某一商品，对数据库频繁的IO操作，可能会产生数据库崩溃问题（分表分库，读写分离治标不治本），解决方法：基于MQ+库存令牌桶实现。
同时有1万个请求实现秒杀，商品库存只有100个， 实现只需要修改库存100次就可以了：
方案实现流程：商品库存是多少，就提前在redis生成多少对应的库存令牌（这里即为100），在1万个请求中，只要谁能够获取到令牌谁就能够秒杀成功， 获取到秒杀令牌后，在使用mq异步实现修改减去库存。
代码实现：
① 编写生成100个令牌桶接口
② 编写获取token代码，并用mq异步发送
RabbitMQ消费者
@Component
Slf4j
public class StockConsumer {
@Autowired
private SeckillMapper seckillMapper;
@Autowired
private OrderMapper orderMapper;
@RabbitListener(queues = "modify_inventory_queue")
@Transactional
public void process(Message message, @Headers Map<String, Object> headers, Channel channel) throws IOException {
String messageId = message.getMessageProperties().getMessageId();
String msg = new String(message.getBody(), "UTF-8");
JSONObject jsonObject = JSONObject.parseObject(msg);
// 1.获取秒杀id
Long goodsId = jsonObject.getLong("seckillId");
SeckillEntity seckillEntity = seckillMapper.findBySeckillId(goodsId);
if (seckillEntity == null) {
log.warn("goodsId:{},商品信息不存在!", goodsId);
return;
}
Long version = seckillEntity.getVersion();
// 2.减库存
int inventoryDeduction = seckillMapper.inventoryDeduction(goodsId, version);
if (!toDaoResult(inventoryDeduction)) {
log.info(">>>seckillId:{}修改库存失败", goodsId);
return;
}
// 3.添加订单
OrderEntity orderEntity = new OrderEntity();
String phone = jsonObject.getString("phone");
orderEntity.setUserPhone(phone);
orderEntity.setSeckillId(goodsId);
orderEntity.setState(1l);
int insertOrder = orderMapper.insertOrder(orderEntity);
if (!toDaoResult(insertOrder)) {
return;
}
log.info(">>>成功消费seckillId:{}，秒杀成功！", goodsId);
}
// 调用数据库层判断
public Boolean toDaoResult(int result) {
return result > 0 ? true : false;
}
}
③ 提供一个根据用户信息查询秒杀结果接口（实际开发中，也可以根据userId）
@GetMapping("/checkSpike")
public BaseResponse<JSONObject> getOrder(String phone, Long goodsId) {
if (StringUtils.isEmpty(phone)) {
return setResultError("手机号码不能为空!");
}
if (goodsId== null) {
return setResultError("商品库存id不能为空!");
}
OrderEntity orderEntity = orderMapper.findByOrder(phone, goodsId);
if (orderEntity == null) {
return setResultError("正在排队中.....");// 要么还没被mq消费，要么没抢到token令牌
}
return setResultSuccess("恭喜你秒杀成功!");
}
public interface OrderMapper {
@Select("SELECT goods_id,user_phone,stateFROM order_table WHERE USER_PHONE=#{phone} and goods_id=#{goodsId} AND STATE=1")
OrderEntity findByOrder(@Param("phone")String phone, @Param("goodsId")Long goodsId);
}
前端需要写一个定时器，用于查询秒杀成功状态：
前端调用秒杀接口spike，如果秒杀成功的话，返回正在排队中。。。
前端写一个定时器调用checkSpike接口，使用手机号/userId + 商品id查询是否秒杀成功。
（如果调用spike返回售罄，则前端不用写定时器）
三. 网关优化
给大家的福利
零基础入门
对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。
同时每个成长路线对应的板块都有配套的视频提供：
因篇幅有限，仅展示部分资料
网络安全面试题
绿盟护网行动
还有大家最喜欢的黑客技术
网络安全源码合集+工具包
所有资料共282G，朋友们如果有需要全套《网络安全入门+黑客进阶学习资源包》，可以扫描下方二维码领取（如遇扫码问题，可以在评论区留言领取哦）~
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
