分类 后台 下的文章


# 原代码
if (isset($value['r']) ) { // 对比属性值
    if(isset($array[$key]) && $array[$key]==$value['r']){
        $module  = str_replace('[if['.$value['v'].']if]',str_replace('::'.$key.'='.$value['r'].'::','',$value['v']), $module);
    }else{
        $module  = str_replace('[if['.$value['v'].']if]', '', $module);
    }
}else if(isset($value['i'])){// 是否含有属性
    if(isset($array[$key]) && strstr($value['i'],(string)$array[$key])){
        $module  = str_replace('[if['.$value['v'].']if]',str_replace('::'.$key.'^'.$value['i'].'::','',$value['v']), $module);
    }else{
        $module  = str_replace('[if['.$value['v'].']if]', '', $module);
    }
}else if(isset($value['sub'])){ // 是否含有子属性
    if( isset($array[$value['c'][0]][$value['c'][1]])){
        $module  = str_replace('[if['.$value['v'].']if]',str_replace('::'.$key.'::','',$value['v']), $module);
    }else{
        $module  = str_replace('[if['.$value['v'].']if]', '', $module);
    }
}else{
    if (isset($array[$key])) {
        $module  = str_replace('[if['.$value['v'].']if]',str_replace('::'.$key.'::','',$value['v']), $module);
    }else{
        $module  = str_replace('[if['.$value['v'].']if]', '', $module);
    }
}

# 优化后

$origin = '[if['.$value['v'].']if]';
$condit = isset($value['g']) && isset($value['r'])  ? '::'.$key.$value['g'].$value['r'].'::' : '::'.$key.'::' ;
$replacement = str_replace($condit,'',$value['v']);

if ( 
    !isset($value['g']) && !isset($array[$key]) ||
    # 不存在值且不存在对比

    in_array($value['g'], ['>','<','>=','<=','=']) && !(isset($array[$key]) && MIXER::compareValue($array[$key],$value['g'],$value['r'])) ||
    # 对比属性值

    $value['g']=='^' && !(isset($array[$key]) && strstr($value['i'],(string)$array[$key]) ) ||
    # 是否含有属性

    $value['g']=='.' && !(isset($array[$value['c'][0]][$value['c'][1]])) 
    # 是否含有子属性
) {

    $replacement = '';
}

$module  = str_replace($origin, $replacement, $module);

IF ELSE, ||, && 同属于短路逻辑 在效率上差不多,不需要遍历全部结果,而是有一个优先级的递进式判断。 用||来代替if 逻辑上并没有什么差别。只是在代码简洁上做一些优化。

使用三个变量来描述了一些过程中的临时变量,能够更好的理解这些变量在上下文中的含义,结构上也避免了重复的排布,让代码逻辑更加明确,但是理解成本略微增高,不像原版本中完全是平铺直叙的过程描述。

最近正在做appsite框架传统网站架构的拓展、其中不免有SEO的部分。 在网上做了一点功课,meta中的 description比较关键,keywords据说已经不再受搜索引擎的关照了,不过这种事情现在不能盲目相信,既然做一个网站那么还是应该要照顾好关键词。但是没必要付出过高的人力成本,所以我这里想到的还是使用分词扩展来自动生成关键词。 这样做的好处是,无论搜索引擎是否在意关键词,我们有和内容相关度很高的关键词,这不会对我们带来损失。 基于程序算法生成的关键词,不需要我们花费人力成本,包括可以在后台控制是否开启该功能。

我这里选用的是对php支持比较好的 SCWS分词扩展。 如果分词的目的是更多的语义化分析、情感分析等,那还是应该考虑一下其他的分词库,不过基本上没有php支持。

进入正题

- 阅读剩余部分 -

因为最近的一个需求涉及到SEO 所以考虑用php写一套前台,这样可以根据url自动输出完整的页面,这里比较重要的是url rewrite 因为直接使用参数来访问页面一是不具备结构性,不方便基于文件夹管理php的前台页面,二是搜索引擎搜索方面也不友好。 所以要为后台添加一套自适应的rewrite。

以下是为一个SEO网站设计的结构

domain / home

  • /page | /class

  • /action

    • /id
  • ?querys

其URL示例为: https://domain/user/detail/12345/... https://domain/goods/list/... 经过重写转化为: https://domain/?abstract=user&functionality=detail&id=12345... https://domain/?abstract=goods&functionality=list...

今天和罗什孵化器的石总聊项目,我们提到了为了保证一些数据的真实性,需要引入区块链技术,这样我们可以避免像58同城这样的虚假信息漫布的问题。 我们聊了很多除了区块链以外的机制补充,还是很有成果的,但是对于区块链技术的实际实施,我考虑了一下,还是应该使用内部数据库来解决。

主要原因有:

1. 支撑能力有限。

搭建一个互联平台、提供的服务远远大于分布式记账的需要,我们也不是一个单纯的金融平台、我们有大量的数据并不敏感,而且是需要反复维护的,如果完全基于区块链来构建平台,是一种因噎废食的方式,既浪费空间,也会导致系统的容错率极低。

2. 不够灵活。

一个正式的互联网服务平台、需求是多种多样的,我们不能将所有信息全部都放到一个公开的信息链条上、最典型的就是用户的隐私数据,而且也没有这样的必要。如果完全基于区块链构建平台,那么就会导致我们本不需要额外做的隐私问题,需要再投入各种技巧来规避,而且是不能从根本上解决的。 用户隐私泄露、服务器风险增加等问题都不好处理。

为此,我设计了一种基于区块链的链式加密的内部区块系统、我称之为 Inner Block Chain 简称 I-BC

下面介绍一下,内区块链的可信度方案以及具体实现方式

- 阅读剩余部分 -

README.md

后台管理系统结构说明

引入服务端入口(管理后台接口)

  • 初始化管理后台 Manager对象

    • 处理登录、鉴权
    • 处理默认访问路径
    • 初始化权限
  • 引入页面文件

    • header HTML头文件
    • customHeader (自定义)
    • aside 侧边栏导航菜单
    • customAside (自定义)
    • act ( page | default ) 核心内容输出 优先page路径
    • script 通用脚本
    • customFooter 自定义脚本
    • footer HTML底部 ( act页customJS在这里生效 )

系统用户的默认权限设置

90000 超级管理员 80000 管理员

40000 网站编辑 30000 创作者 10000 普通用户

redis没有表的概念

由于没有数据表的概念、我们很多基于关系型数据库的查询方式、在Redis服务器上就要有新的思路。 譬如说我们通过4张表来维护用户数据、在redis上就应该只使用一个Hash 另外类似于Comment这样的表,我们就需要设计成Redis List类型 以COMMET_USERID来作为key 每一次添加一条反序列化数据进去。但这样做面临的问题是我们无法使用关系型表的其他诸如合并查询、反向查询等查询功能。

redis服务密码验证访问

配置文件中配置 requirepass yourpassword

数据库层级的访问控制

目前没有方案 考虑中 这个部分也和java服务端的朋友讨论过,Redis确实没有这方面的支持,如果考虑同一个redis服务器中有多个或者大量Saas需求、那么比较好的方式就是在最前面加一个appid的索引。

探索一下几种实现方式:

# 以saasID作为key userid做其中一项的方式
hset TRFUnmsZ userid qFVqmqMz nickname sprite
hset gdYuSu4G userid hGE5REy2 nickname amber

# 以userid作为key saasid作为其中一项
hset qFVqmqMz saasid TRFUnmsZ nickname sprite
hset Lh8PCIVy saasid TRFUnmsZ nickname soki
hset gdYuSu4G saasid hGE5REy2 nickname amber

# 以saasid拼接 keyid的方式
hset TRFUnmsZ_qFVqmqMz nickname sprite
hset TRFUnmsZ_Lh8PCIVy nickname soki
hset hGE5REy2_gdYuSu4G nickname amber

hset TRFUnmsZ_SETTING WECHATID 123456
hset TRFUnmsZ_SETTING APPNAME AppSite
hset hGE5REy2_SETTING WECHATID 654321

基于Redis只能通过key进行查询、不能使用类似于MySQL的WHERE查询,所以用saasid作为key的方式被摒弃。我们不可能取出所有的saas下的数据 再到程序里查找。

- 阅读剩余部分 -

在网上可以查到有两种方式查询表的索引

show index from tablename
SELECT * FROM mysql.innodb_index_stats a WHERE a.database_name = '数据库名' and a.table_name like '%表名%';

第一种是可行的,问题是在于并不是用SELECT语句,所以就不能和其他的表数据一起查询,譬如说 查询表结构的时候连同索引一起查询。

(第二种来自于网络,实际上语句本身就有错误和低效的like,我们先只看逻辑) 仅看第二种也是不可行的,因为除了ROOT用户以外的用户无法访问innodb_index_stats表,所以是不行的。 在网上翻了很多页面都没有找到合适的解决方案,于是我把所有独立数据库用户身份可以查看的表全部翻看一遍之后发现。STATICS表中是存有索引数据的。

查询方式如下:

SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = basename AND TABLE_NAME = tablename

将索引信息和表结构信息一起查看的查询:

SELECT * FROM INFORMATION_SCHEMA.COLUMNS LEFT JOIN INFORMATION_SCHEMA.STATISTICS ON COLUMNS.COLUMN_NAME=STATISTICS.COLUMN_NAME AND COLUMNS.TABLE_NAME = STATISTICS.TABLE_NAME AND  STATISTICS.TABLE_SCHEMA = '{$basename}' AND STATISTICS.TABLE_NAME = '{$tablename}' WHERE COLUMNS.TABLE_SCHEMA = '{$basename}' AND COLUMNS.TABLE_NAME = '{$tablename}' 

这里一定要注意使用表内筛选 先将STATISTICS表中的数据过滤一遍,再进行合并,两张表都要以basename,tablename进行过滤。否则会有很大概率得到循环嵌套的大量结果!

  1. From:

mysql分别用数字INT和中文varchar做索引查询效率上差多少

性能相当

mysql中区别性能的是采用哪种索引方式,而不是索引的数据类型。

MySQL的btree索引和hash索引的区别

  1. hash 索引结构的特殊性,其检索效率非常高,索引的检索可以一次定位,
  2. btree(B-Tree)索引需要从根节点到枝节点,最后才能访问到页节点这样多次的IO访问,
  3. 综上,hash 索引的查询效率要远高于 btree(B-Tree) 索引。 虽然 hash 索引效率高,但是 hash 索引本身由于其特殊性也带来了很多限制和弊端,主要有以下这些。

- 阅读剩余部分 -