13518219792
如果是数据库，可以使用数据库的锁机制，如果你是想要在自己的程序中进行控制，那么可以使用同步机制，谁先抢占到票的资源谁就获得该资源的处理权限，其它的申请存于请求队列中，或者干脆直接拒绝。
公司主营业务：网站设计制作、成都网站设计、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。创新互联是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联推出绿春免费做网站回馈大家。
由秒杀引发的一个问题
我们假设现在商品只剩下一件了，此时数据库中 num = 1；
但有100个线程同时读取到了这个消息 num = 1 ，所以100个线程都开始减库存了。
但你最终会发觉， 其实只有一个线程减库存成功，其他99个线程全部失败。
为何？
这就是MySQL中的排他锁起了作用。
排他锁又称为写锁，简称X锁，顾名思义，排他锁就是不能与其他所并存， 如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁 ，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。
就是类似于我在执行update操作的时候，这一行是一个事务 (默认加了排他锁 )。 这一行不能被任何其他线程修改和读写
这种方式采用了 版本号 的方式，其实也就是 CAS 的原理。
假设此时version = 100， num = 1; 100个线程进入到了这里，同时他们select出来版本号都是version = 100。
然后直接update的时候，只有其中一个先update了，同时更新了版本号。
那么其他99个在更新的时候，会发觉version并不等于上次select的version，就说明version被其他线程修改过了。那么我就放弃这次update
利用redis的单线程预减库存。比如商品有100件。那么我在redis存储一个k,v。例如
每一个用户线程进来，key值就减1，等减到0的时候，全部拒绝剩下的请求。
那么也就是说只有100个线程会进入到后续操作。所以一定不会出现超卖的现象
可见第二种CAS是失败重试，并无加锁。应该比第一种加锁效率要高很多。 类似于Java中的Synchronize和CAS 。
1、可以使用源代码监测软件进行检测，它能够快速扫描整个源码，并检测其中的可疑字符串，如果发现有任何可疑的字符串，就会发出警告。
2、源代码文件也可以使用特征哈希技术进行比对，它可以检测出源代码文件是否与其他文件相同，如果发现有不一致的情况，就可以判断是二次倒卖。
3、可以使用版权保护工具，它可以防止源代码被倒卖或者盗版，同时也可以追踪被倒卖的源码，以便及时发现二次倒卖的行为。
