1、 一定要逐步考虑安排分库分表
(1) 用户表、商品表、订单表等基本表必须要考虑分库分表，要不未来随着量大很容易出现异常。
(2) 首页、列表页等聚合页面，通过数据冗余，在分库分表后多写一份，以达到查询时直接使用索引，2秒内返回结果的目的
电商99%以上的量都是读，只要通过分库分表和多写些冗余数据的方式就可以提升性能，解决掉目前电商系统的根本问题
2、 技术语言
前端PHP，后端JAVA这样搭配着比较好。
如果已经全部是PHP或者JAVA了，也就别再换了，性价比不高
直接采用linux系统就好。初创企业，用云服务即可。
3、 日志流水的添加
所有的写操作(增、删、改)都要记录完善的日志，且记录下来：此次操作是否成功，以及耗时多少毫秒，如果不成功，还要记录当前所有环境变量，如果是数据库操作，最好把sql语句都记录下来。读操作如果量大，可以考虑把后台返回结果超过2秒的读请求记录，监控这块的量，超过2秒还没返回，用户多半就跑了
这个非常有必要，一个“可运营”、“可维护”的电商系统差别就差在这里。
4、 必须要做风控
日志流水的作用就出来了。通过读取日志流水，生成几个必备的监控
(1) 每隔10分钟，监控异常的：注册、登陆、下单、支付以及异常的金额等，让风险控制在10分钟内。
(2) 按天生成研发报表。
|
**接口 |
昨日执行次数 |
成功率 |
失败率 |
0-500毫秒 |
500毫秒-1秒 |
1-2秒 |
2秒以上 |
(3) 每天生成产品运营报表
|
多少人登陆 |
多少人下单 |
多少人支付 |
多少人付款 |
登陆失败多少人 |
下单失败多少人 |
取消订单多少人 |
等等明细数据。产品运营每天检测这些数据
5、 初步的架构
（1） 接入层，别考虑apache，直接升级到nginx
（2） 逻辑层用php，java都行
前台最好是ajax直接请求逻辑层jason数据，千万别用基础的框架打包一个html直接返回给前台。系统会出现白屏然后瞬间有内容了，前端性能优化可以参考：雅虎前端优化规则 (百度一下就行)
（3） cache用redis最好(数据结构丰富)，memcache也行(session等可以放到memcache里)
cache的更新采用key-value，后台一旦修改，实时更新。千万别用多少分钟后让key全部失效，全部更新，那样体验太烂，经常会出现数据不同步。
（4） 数据库mysql直接用innodb就行。分库分表后sql语句就不会出现嵌套查询、关联查询(这个是系统慢的最根源问题)
6、电商系统必须要注意的2个技术问题
(1)、同一个请求被发送了多次
可能出现的地方：(1)和别人接口对接，别人同一份数据发送了多次
(2)用户在“提交”按钮里点击了多次
(3) 其他可能的一些恶意调用，尤其是涉及支付环节的，危险性非常大
解决办法：(1) 在网页端，用户点击“提交”后，将按钮disable掉
(2) 对于收到的数据插入到数据库或者其他一些地方，做好唯一键控制
把用户提交的内容+精确到秒的时间合并成一个字符串，然后md5一次，插入到数据库里作为唯一键控制。
(2)、同一秒内有多次请求
这个就是并发控制，涉及到抽奖等等需要控制到数量的地方，控制不好，会出现抽奖抽多了，卖东西卖超了等情况
出现的原因也很清晰，同一秒内收到多个请求，分布式的，可能不同的请求会分布到不同的机器或者程序上去执行，都去读取一下计数器(记录卖的数量)，比如：1，每个请求都各自执行读取操作，发现都是1，没有超出1的限制，然后都来修改计数器为0，然后各自都去发货或者发送奖品，结果造成了卖超。
解决办法：
利用数据库或者其他有并发控制的程序来做一个锁的逻辑
利用数据库的话，有一个小技巧提供给大家
伪代码如下：
[php] view plaincopy
1. //字段A里存储的是计数器数字
2. select A from 表B；
3. $a = A;
4. if ( $a <= N && $a > 0)
5. {
6. update A=A-1 where A<=N and A >= 0;
7. //如果执行成功，则可以领取奖品
8. //这样可以控制并发时只卖掉N个奖品
9. }
电商项目的运营可以参考之前写的这篇文章：http://blog.csdn.net/eroswang/article/details/8185676