Qq网站设计运营 第1篇
成熟的互联网公司通常都会有自己的安全团队，一般通过数据建模的方式，搭建出一个恶意用户黑名单的数据库，然后持续维护这些恶意账号和IP等信息，更新数据。然后，我们这个服务接入到里面去。恶意工作室手持大量的账号和IP，而我们通过这个恶意数据库，将它们拦截掉。
但是，数据建模的算法不管如何精细，为了防止误杀真实用户，总会存在打击率的问题，它们通常无法拦截下全部恶意请求，总会有少数的漏网之鱼。
而我们所思考的，就是在这个基础上，结合业务，增加新的安全保护策略。可能会有很多人会想，追加参与门槛是否可以取得进一步的保护效果呢？例如，在传统安全打击策略的基础上，再加上业务限制，例如将活动参与条件设置为超级会员（20元一个月的付费会员），这样的话，我们以更高的门槛来拦截恶意请求。
在以前很长一段时间里，我都认为这种方法应该是靠谱的，因为提高了参与的门槛。直到有一次，我们捕获到一批好几万的恶意QQ号码（都是一些号码很长的垃圾号码），它们竟然全部都是超级会员，恶意工作室竟然花费了不少钱给它们开通20块钱一个月的超级会员。从那个时候开始，我开始明白，付费会员身份限制，也是不可靠的。
超级会员的身份带给这些恶意号码更多的便利，反而可以给它们获取更多高价值礼包的机会，将获得东西兑现成金钱，然后覆盖掉恶意工作室的“投资成本”。
Qq网站设计运营 第2篇
我们通过构建高效的活动开发模式，促使我们AMS运营平台的业务规模和流量规模，都在过去的三年多时间里，出现了100倍的增长，同时在线的活动超过1000个。与此同时，AMS平台的可靠性和稳定性，也成为至关重要的指标之一，平台如果出问题，影响面变得很广。
AMS平台的架构分为四个层级，分别为：入口层、业务逻辑层、服务层、存储层（CKV的NoSQL存储），还有一个离线服务和监控系统。
Qq网站设计运营 第3篇
基于这个问题，我们当时想到的第一个解决方案，就是整合前端和后端组件，重新搭建一个结构清晰和统一的系统。将这个系统的接口分层、复用、简化的原则，逐步构建一个完整的体系。而且，从我们开发的角度来说，最重要的目的，是为减少活动开发的工作量，解放开发人员，提升研发效率。
我们的前端组件通过一个叫Zero的框架统一整合，前端每一个功能以组件的形式出现，统一维护和复用。CGI层则进行了代码重构，实行框架驱动式开发，将每一个业务逻辑功能，收归到一个唯一的入口和统一的体系中。核心功能框架自动支持，已有活动功能组件可直接配置使用。如果没有新的功能接入，运营开发只需要配置一份简单的参数，就可以完成后端功能逻辑，不再需要写代码。对于基础支撑服务，则以平台化的模式进行管理，做统一接入和维护。
当我们做完系统结构的调整后，我们终于实现，通过一份活动配置，来控制前端和后端的组件组合。每一个条件、发货等动作，都可以随意动态组合，参与条件通过“与”、“或”、“非”等组合方式，选择对应的动作，实现活动功能逻辑。
从那时开始，活动开发变得简单了不少，需要写的代码大幅度减少，基本变成“填写参数”的工作。一个活动项目的代码从之前的1000-2000行，变成了不到100行。
例如，如下图中，本来需要写不少逻辑代码的领取礼包，在前端只变成了一行参数。
清晰的结构提升了系统可维护性，更为重要的是，活动开发效率也得到了极大的提升。
在开发人力不变的情况下，我们活动开发的效率实现了大幅提升，产品的需求积压的情况，得到有效的缓解。
Qq网站设计运营 第4篇
2012年初，也就是在AMS产生之前的活动开发模式，相对比较随意，也并没有一套严格和完整的框架支持，组件的复用程度不够高。因此，我们开发一个活动，经常需要耗时1周多。当时，开发活动的其中一个特点就是“各自为政”，每个运营开发同学，各自产生了一批前端和后端组件，CGI层也产生了很多不同规则的入口。这些各自实现的组件，结构比较凌乱，不成体系，维护起来也比较困难。最重要的是，这样的组件对于活动开发来说，使用复杂，复用率低，以至于开发效率也比较低。
在当时，活动运营需求也出现了一定程度上的堆积，很多需求没有人力支持，产品同学也觉得我们上线活动比较慢。
Qq网站设计运营 第5篇
最后，通过QQ空间和腾讯微博进行推广，现在百度分享和bShare分享已经很强大了，很多网站也都用上了这种分享，它可以将网站内容分享到人人网、新浪微博、QQ空间、腾讯微博等等，总之可以分享到多个第三方平台，然后让更多的用户看到，但QQ类型的门户网站只需要做QQ空间和腾讯微博分享就可以了，这两种是最有针对性和相关性的，分享后可以让QQ用户看到这些分享信息，另外就是在QQ空间和腾讯微博上发布内容，让更多的人看到，这种方法的效果也是非常不错的。
举个简单的例子：笔者在自己的QQ说说大全网站里添加了分享插件，然后每天都推送一些信息到QQ空间和腾讯微博上，笔者是在一定的时间内进行推送的，然后自主的在QQ空间说说上和腾讯微博上发布一些QQ说说的句子，通常QQ用户都会关注这些信息的，然后慢慢养这些信息，过不了多久就会强大了。
想要最好QQ类型的门户网站推广工作，不光靠的是实战还得需要花样，不光你在做，其他的站长们也在做，只有做的最好的那个才会获取最好的效果，同样，推广的手段是层出不穷，慢慢研究一定会研究出新的推广方法。
Qq网站设计运营 第6篇
秒杀在活动运营中，是比较常见的一种参与形式，它带来的挑战除了流量冲击的问题，还会带来高并发下的业务逻辑安全问题。这个时候，我们必须引入适当的锁机制，来规避这些问题。它和线程安全是同一类型的问题。
首先是用户的session锁，也就是说，同一个子活动功能中，同一个用户，在前一次发货请求结束之前，禁止第二个请求。之所以要这样做，是因为，如果同一个用户发起两个并发请求，在一个临界时间内，可能导致礼包多发。
例如下图中的A用户，在第一个请求成功写入参与成功标志位之前，第二请求是可以通过“条件判断“，仍然可以进入发货环节，这样的话，就可能会让A用户获得2个礼包。
还有一个锁是基于多个用户的秒杀保护锁，场景是类似的，Session锁，只是变为多个并发用户，请求同一个礼包，同样在判断礼包余量数目的临界时间里，有可能产生“超发“（礼包多发了）。
问题很明显，采用锁当然就可以解决，但是，采用何种的锁机制，又是一个值得思考的问题。因为，业务场景不同，选择的解决方案自然不同。我们从三个不同的思路，来讨论秒杀的实现机制。
我们业务锁采用的是乐观锁的实现方式，因为我们的一个发货流程通常耗时超过100ms，在高并发下，都容易产生请求积压，导致我们无法做到实时反馈。我们的实现，确保不管用户是否请求秒杀成功，都能在500ms内获得实时反馈。并且，我们将这个实现广泛使用到各个秒杀和抢购活动中，曾经支撑过5w/s的秒杀活动，表现非常平稳和安全。
Qq网站设计运营 第7篇
通过对不同业务的活动模式的分析和抽象，我们发现事实上绝大部分活动都可以用一组“条件”和“动作”的方式进行抽象和封装，进而形成通用的“条件”（Rule）和“动作”（Operation）活动组件，不同条件和动作的组合使用，变成活动逻辑的实现。然后，我们希望通过平台化和框架驱动开发的方式，将这些组件统一封装。同时，在框架和平台层面，为活动组件的运行提供高可靠、高性能、具备过载保护和水平扩展能力的框架支撑环境。
活动组件只需要封装自身业务逻辑，核心功能框架自动支持，从而实现活动运营开发的彻底自动化。
AMS所需要承担的任务，就是实现这个规划。需要面临的，主要是解决三个方面的问题：
（1）建设高效活动开发模式（运营开发自动化）。
（2）搭建高可靠性和高可用性的运营支撑平台。
（3）保证活动运营业务的安全。
Qq网站设计运营 第8篇
开发一个活动本身需要一定的工作量。尤其是大型的推广活动，这类型的活动对功能和性能的要求比较高。一个典型的大型活动通常有数千万的用户参与，因此，对性能要求比较高，如果再涉及到“秒杀”或者“抢购”类型的高并发功能时，对于基础支撑系统是一个强力的挑战。
活动功能众多，包括礼包、抽奖、分享、邀请、兑换、排行、支付等，这些不同的参与和表现形式，也会涉及更多的后端接口通信和联调。例如，我们的游戏运营业务涉及上百款游戏，而不同的游戏对应不同的服务接口，就游戏相关的通信接口，就涉及上千个。
还有一个非常重要的问题，就是活动运营的安全和可靠性。因为，我们的活动，大多涉及较重要的实物奖品发放，如iphone、ipad等高价值礼包，对安全要求很高。