EC logical & technical sum

logical :

数据存取：

表单父子关系（一条对多条数据）：商品+配送

表单关联关系（一张表对多个表）：购物+订单

表单状态关系（一个状态变多个）：预存款+退货退款

第三方：支付+分享







页面呈现：首页 导航 推荐位 广告 | 商城 购物车 订单

通用模块：防灌水 第三方登录和分享 上传 SEO 通知 | 权限 分类 状态 审核

电商核心：支付 订单 购物车 配送 退款退货 | 团购 促销 会员 商品 商户 优惠券 统计 | 结算 预存款




功能模块：

框架：功能==>表单==>流程

要点：会员黏性 商品分类 促销种类 购物车添加 配送信息 订单生成 异步支付 退货退款流程 预存结算金额 统计转化 团购优惠券发布

cms+sns+im

其他：防灌水 第三方登录和分享-qq sina taobao/alipay

+防灌水

1、全局--注册与访问控制

2、全局--防灌水设置

3、用户--用户组设置

4、用户--用户栏目

5、云平台--防水墙

6、内容--词语过滤

7、应用--防灌水插件

+第三方登录

应用向服务申请请求令牌 request Token (应用的账号密码)

应用向服务申请授权令牌 authToken（用户的账号密码）

应用向服务申请accessToken（访问用户资源的秘钥）

应用向服务申请opendiD,它和用户账号相对应（权限的唯一性）

应用访问服务的受保护资源，通常是用户的信息
http://www.cnblogs.com/neutra/archive/2012/07/26/2609300.html


technical:

http save(session cookie $_SERVER) + cache save (memache redis file )

session

+4 point+ server分配session_id给client（client +server 的生存时间可设定），client保存在file or cache,用时传给cookie,

+3 point+ session_id() = $_COOKIE[session_name()];关闭浏览器后，session_id就变了，server给client重新分配了session_id(),而且是，第二次刷新才会显示在 $_COOKIE[session_name()]里

session_start();

echo session_name().'<br>';

echo session_id();//关闭浏览器，重开后，session_id的值就变了

echo $_COOKIE[session_name()];//而且第一次取不到，第二次刷新网页才会显示的

参数

session_id() = $_COOKIE[session_name()];

session.name = PHPSESSID //默认值.这个就是SessionID储存的变量名称，可能是Cookie来传递，也可能是Query_String来传递（get方法?后面的），默认值是"PHPSESSID"

//time client or server

Session.cookie_lifetime:这个代表SessionID在客户端Cookie储存的时间，默认值是“0”，代表浏览器一关闭，SessionID就作废，就是因为这个原因，所以Session不能永久使用。

Session.gc_maxlifetime:这个是Session数据在服务器端储存的时间，如果超过这个时间，那么Session数据就自动删除。

//with cookie 通过cookie不，存在cookie下的哪儿,cookie管多大的事儿（域名）

session.cookie_domain = ; ;sessionid的cookie域名，不需要修改,二级域名才需要改

session.cookie_path = / ; sessionid的cookie路径，不需要修改

session.cookie_httponly 它是用来解决浏览器里javascript访问cookie的问题

session.use_cookies:默认值为"1",代表SessionID使用Cookie来传递，反之就是用Query_String来传递（get传值）。

//save where 存哪儿 file or memcache or redis

session.save_handler = files ; 这个是session的方式，默认的files就可以了，代表用文件储存，还有两种方式，user和memcache。user方式指的是你自己（也就是用户）定义session的句柄，用于session的存取等，这个可以把session扩展存到数据库里，memcache方式，需要你配置好memcache,还要配置session.save_path。

session.save_path = /tmp ; 这个是session的保存路径，比如你系统盘是c盘，那么默认就是c:/tmp，所以如果出现"Warning: open(/tmpsess_cc8b04f146a1e0494bc464305da92ea1, O_RDWR) failed"这样子的错误，你可以修改这个路径，或者在根目录下面建立一个tmp的文件夹

session.auto_start = 0 ; 是否自动启动session，默认为不是，不需要修改

session.referer_check = ; How many bytes to read from the file.

返回值

session_start();

echo session_name().'='.session_id();

运行结果：PHPSESSID=4d8d3ep8cakmvto6hvut3mphf4

session_name() 默认为 "PHPSESSID"

而 session_id() 是 一次HTTP 请求,服务器得到的 $_POST['PHPSESSID'] 或者 $_GET['PHPSESSID'] 或者 $_COOKIE['PHPSESSID']

如果你在 session_start() 前调用了 session_name('SID'); 那么正常情况下（客户端支持Cookie时）, 会给客户端发送 Set-Cookie: SID=(session_id 的值);

代码段

//session.name强制定制成PHPSESSID,不请允许更改

@ini_set('session.name','PHPSESSID');

$subdomain_suffix = str_replace('http://','',$subdomain_suffix);

if ($subdomain_suffix !== 'localhost') {

@ini_set('session.cookie_domain', $subdomain_suffix);//指定域名，让二级域名的session也能存进去

}

//开启以下配置支持session信息存信memcache

/*@ini_set("session.save_handler", "memcache");

@ini_set("session.save_path", C('memcache.1.host').':'.C('memcache.1.port'));*/

//默认以文件形式存储session信息

session_save_path(BASE_DATA_PATH.'/session');

session_start();

/***************session developed*******************/

session 串号：

现象：就是产生了相同的session_id

原因：用户量大导致的sessionId相同或并发导致的相同

详细：

1)session的id一般的是保存在cookie里面的，访问时客户端的id同服务器端的id相匹配。

一种有可能是因为算法问题导致的id在生成的时候出现了“碰撞",这种情况一般很难遇到，但是基于微博巨大的用户数量因而这类碰撞的产生就会有可能发生，

毕竟基数太大了，难免有特例。

2)另一种，目前的服务器后台一般的都是集群处理的，有可能是在处理并行的时候没有处理好，有可能两台不同的服务器为不同的账号生成了相同的id

session 共享：

目前网上能找到的方案有：db nfs cache redis cookie + other

1.基于数据库的Session共享

2.基于NFS共享文件系统

3.基于memcached 的session，如何保证 memcached 本身的高可用性？

4.基于resin/tomcat web容器本身的session复制机制

5.基于TT/Redis 或 jbosscache 进行 session 共享。

6.基于cookie 进行session共享

session 集群：客户端 + 集中共享 + 复制

随着互联网应用的用户量不断激增，并发的需求越来越受到开发者的关注，通过集群的方式来解决web的瓶颈。但是集群的session共享是个比较头疼的事情，归结起来就三种解决方案：

（1）客户端存储方案：把session加密后存在cookie中,每次session信息被写在客服端,然后经浏览器再次提交到服务器.即使两次请求在集群中的两台服务器上完成,也可以到达session共享.这种解决方法的优点是session信息不用存放在服务器端,大大减轻了服务器的压力.另一个优点是一个session中的两次或多次请求可以在一个群集中的多个服务器上完成,可以避免单点故障.目前,淘宝是采用的这种解决方案.

这个方案可能比较陌生，但它在大型网站中还是比较普遍被使用。原理是将全站用户的Session信息加密、序列化后以Cookie的方式，统一种植在根域名下（如：.host.com），利用浏览器访问该根域名下的所有二级域名站点时，会传递与之域名对应的所有Cookie内容的特性，从而实现用户的Cookie化Session 在多服务间的共享访问。

这个方案的优点无需额外的服务器资源；缺点是由于受http协议头信心长度的限制，仅能够存储小部分的用户信息，同时Cookie化的 Session内容需要进行安全加解密（如：采用DES、RSA等进行明文加解密；再由MD5、SHA-1等算法进行防伪认证），另外它也会占用一定的带宽资源，因为浏览器会在请求当前域名下任何资源时将本地Cookie附加在http头中传递到服务器。

（2）集中式session共享方案：提供一个群集保存session共享信息.其他应用统统把自己的session信息存放到session群集服务器组.当应用系统需要session信息的时候直接到session群集服务器上读取.这种方式具有第一种方式的第二个优点.

（3）session复制方案：配置负载均衡服务器,让用户的一个session在一个服务器完成.定时的备份session信息到salve上面.一台服务器down掉后,通过均衡服务器透明把用户的请求转发到群集中的其他服务器上,此时需要从salve上读取备份的session信息.

附：《淘宝的无状态共享架构》

负载均衡 vs 失效恢复

俗话说，一个系 统的伸缩性的好坏取决于应用的状态如何管理。

为什么这么说呢？咱们试想一下，假如我们在session中保存了大量与客户端的状态信 息的话，那么当保存状态信息的server宕机的时候，我们怎么办？

通常来说，我们都是通过集群来解决这个问题，而通常 所说的集群，不仅有负载均衡，更重要的是要有失效恢复failover,比如tomcat采 用的集群节点广播复制，

jboss采 用的配对复制等session状 态复制策略，但是集群中的状态恢复也有其缺点，

伸缩性：

那就是严重影响了系统的伸缩性，系统不能通过增加更多的机器来达到良好的水平伸缩，因为集群节点间session的 通信会随着节点的增多而开销增大，

因此要想做到应用本身的伸缩性，我们需要保证应用的无状态性，这样集群中的各个节点来说都是相同的，从而是的系统更好的 水平伸缩。

客户端：

OK，上面说了无状态的重要性，那么具体如何实现无状态呢？此时一个session框架就会发挥作用了。幸运的是淘 宝已经具有了此类框架。

淘宝的session框架采用的是client cookie实现，主要将状态 保存到了cookie里 面，这样就使得应用节点本身不需要保存任何状态信息，

这样在系统用户变多的时候，就可以通过增加更多的应用节点来达到水平扩展的目的.但 是采用客户端cookie的 方式来保存状态也会遇到限制，

比如每个cookie一般不能超过4K的大小，同时很多浏览器都限制一个站点最 多保存20个cookie.淘 宝cookie框 架采用的是“多值cookie”，

就是一个组合键对应多个cookie的 值，这样不仅可以防止cookie数 量超过20， 同时还节省了cookie存储有效信息的空间，因为默认每个cookie都会有大约50个字节的元信息来描述cookie。

持久化：

除了淘宝目前的session框 架的实现方式以外，其实集中式session管理来完成，说具体点就是多个无状态的应用节点连接一个session服务器，

session服务器将session保存到缓存中，session服务器后端再配有底层持久性数据源，比如数据库，文件系统等等。

* 设置cookie

*

* @param string $name cookie 的名称

* @param string $value cookie 的值

* @param int $expire cookie 有效周期

* @param string $path cookie 的服务器路径 默认为 /

* @param string $domain cookie 的域名

* @param string $secure 是否通过安全的 HTTPS 连接来传输 cookie,默认为false

*cookie 前缀，strtoupper->substr->md5

memory use : memory_get_usage

取上一步来源地址 : $_SERVER['HTTP_REFERER']

对象实例:

* 实例化-->类-->方法-->参数

* call_user_func_array

url 拼接：

实例：http://localhost/aaa/index.php?p=222&q=333

结果：

$_SERVER['QUERY_STRING'] = "p=222&q=333";

$_SERVER['REQUEST_URI'] = "/aaa/index.php?p=222&q=333";

$_SERVER['SCRIPT_NAME'] = "/aaa/index.php";

$_SERVER['PHP_SELF'] = "/aaa/index.php";

$_SERVER['argv'][0] = "p=222&q=333"

(

一般会认为

$_SERVER['argv'][0] = "p=222"

$_SERVER['argv'][1] = "q=333"

但实际上却是

$_SERVER['argv'][0] = "p=222&q=333"

)

由实例可知：

$_SERVER["QUERY_STRING"] 获取查询 语句，实例中可知，获取的是?后面的值

$_SERVER["argv"] 获取参数，获取的是?后面的值

$_SERVER["REQUEST_URI"] 获取 http://localhost 后面的值，包括/

$_SERVER["SCRIPT_NAME"] 获取当前脚本的路径，如：index.php

$_SERVER["PHP_SELF"] 当前正在执行脚本的文件名

func_get_arg：

function jb51(){

print_r(func_get_args());

echo "<br>";

echo func_get_arg(1);

echo "<br>";

echo func_num_args();

}

jb51("www","jb51","net");

输出结果：

Array ( [0] => blog [1] => micxp [2] => com )

micxp

3

从上面的结果中我们就可以看出

func_get_args() 这个函数返回的是包含当前函数所有参数的一个数组

func_get_arg() 函数返回的是指定位置的参数的值

func_num_args() 这个函数返回的是当前函数的参数数量 返回的是数字

cache：

写入缓存参数 : key val ttl +prefix serialize

读/写 缓存方法：额外的变量

额外的存储了键名key 到static静态变量$cache中去，全局就能使用了:

一般的函数内变量在函数结束后会释放，比如局部变量，但是静态变量却不会。

就是说，下次再调用这个函数的时候，该变量的值会保留下来。

$cache[]是个数组，添加新key 的时候，它会不断的保留前面添加的key，使其不会失效，&是不是也有相同的功效

memcache和redis都需要给key值设定不同的type前缀，来区分业务逻辑

memcache必须设定expire 过期时间，但是redis可设定，也可单独设定 ttl

redis要考虑主从读写不同的库

file 函数 realpath