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